Management and control of mobile computing device using local and remote software agents

ABSTRACT

Devices, systems, and methods for allowing parents to view and track smart phone activities of their children can include one or more child software modules. The module can be installed on each child&#39;s smart phone. The module can access and extract data from or about more than one of the smart phone&#39;s other software applications, including at least two of the following: a texting application, a social media application, an image application that facilitates transmission or reception of images, and a web browser application. The module can further send the extracted data to an analysis server. The module can also monitor location data. Moreover, the system can include an analysis server that can identify potentially harmful language, images, and websites. Further, the system can include a parent portal. The parent portal can receive results from the analysis server.

PRIORITY AND INCORPORATION

Any and all applications for which a foreign or domestic priority claimis identified in the Application Data Sheet as filed with the presentapplication are hereby incorporated by reference under 37 CFR 1.57. Inparticular, the present application is a continuation of applicationSer. No. 16/355,367, filed Mar. 15, 2019, titled MANAGEMENT AND CONTROLOF MOBILE COMPUTING DEVICE USING LOCAL AND REMOTE SOFTWARE AGENTS, whichis a continuation of application Ser. No. 15/192,619, filed Jun. 24,2016, titled MANAGEMENT AND CONTROL OF MOBILE COMPUTING DEVICE USINGLOCAL AND REMOTE SOFTWARE AGENTS and issued as U.S. Pat. No. 10,237,280on Mar. 19, 2019, which claims priority benefit under 35 U.S.C. § 119(e)to: U.S. Provisional Patent Application Ser. No. 62/184,797, filed Jun.25, 2015, titled MANAGEMENT AND CONTROL OF MOBILE COMPUTING DEVICE USINGLOCAL AND REMOTE SOFTWARE AGENTS; and to U.S. Provisional PatentApplication Ser. No. 62/354,054, filed on Jun. 23, 2016. The entiredisclosure of each of the above items—including any appendicesthereof—is hereby made part of this specification as if set forth fullyherein and incorporated by reference for all purposes, for all that theycontain.

BACKGROUND

As technology and web access becomes more pervasive and accessible toyounger users, it can sometimes affect child safety and well-being. Forexample, smart phones and other devices can expose children to contentunapproved by parents. Moreover, the historical problem of physicalbullying in the schoolyard is increasingly being eclipsed by social andphysical threats, vulgarity, and similar problems perpetrated by thecyber bully. Impressive new electronic devices and social mediaplatforms can unfortunately amplify the harmful actions of the cyberbully. Cyberbullying can include tormenting, threatening, harassing,humiliating, embarrassing or otherwise targeting an individual usinginformation or communication devices. It can be particularly pervasiveamong juveniles.

SUMMARY

Example embodiments described herein have several features, no singleone of which is indispensable or solely responsible for their desirableattributes. Without limiting the scope of the claims, some of theadvantageous features will now be summarized. Methods and systems aredisclosed for controlling and monitoring aspects of user systems, whichmay include mobile electronic devices.

In some embodiments, a system and apparatus for allowing parents to viewand track smart phone activities of their children can include one ormore child software modules. The module can be installed on each child'ssmart phone. The module can access and extract data from or about morethan one of the smart phone's other software applications, including atleast two of the following: a texting application, a social mediaapplication, an image application that facilitates transmission orreception of images, and a web browser application. The module canfurther send the extracted data to an analysis server. Moreover, thesystem can include an analysis server that can identify potentiallyharmful language, images, and websites by comparing the extracted datato existing databases of harmful words, harmful images or image types,harmful websites, and harmful applications. Further, the system caninclude a parent portal. The parent portal can receive results from theanalysis server. In some embodiments, the parent portion can display theresults organized by child. The parent portal can also provide bothgeneralized smart phone usage data for each child and visual warningswhen harmful results have been found by the analysis server, along withthe specific underlying data that triggered the warning. Furthermore,the parent portal can provide an interface for receiving input from aparent. The input can include selections of which child's data to viewand/or selections of which types and how much of the data and analysisresults to view for each child.

A system and apparatus for allowing parents to view and track smartphone activities of their children can also include the followingfeatures: each child software module can be configured to access andextract data sufficient to allow the analysis server to report which newapplications are downloaded to each child's smart phone, and thatinformation can be automatically recorded in a computer memory anddisplayed promptly through the parent portal. A system and apparatus forallowing parents to view and track smart phone activities of theirchildren can also include the following features: each child softwaremodule can be configured to access and extract data sufficient to allowthe analysis server to report each of the following: which websites werevisited using each child's smart phone; and content and timing of eachchild's posts to social networks. That information can be automaticallyrecorded in a computer memory and displayed promptly through the parentportal.

A system and apparatus for allowing parents to view and track smartphone activities of their children can also include the followingfeatures: each child software module can be further configured to accessand extract data sufficient to allow the analysis server to report eachof the following: the location of the smart phone at periodic intervalsthroughout the day; and usage of the smart phone that occurs outside ofgeographic constraints that can be set through the parent portal. Thatlocation and usage information can be automatically recorded in acomputer memory and displayed promptly through the parent portal. Asystem and apparatus for allowing parents to view and track smart phoneactivities of their children can also include the following features:each child software module can be further configured to access andextract data sufficient to allow the analysis server to report usage ofthe smart phone that occurs during curfew periods, and that informationcan be automatically recorded in a computer memory and displayedpromptly through the parent portal.

A system and apparatus for allowing parents to view and track smartphone activities of their children can also include the followingfeatures: for each child, the parent portal can be configured to displaythe following information on the same daily feed screen: identities ofpeople with whom that child communicates most often, including a visualindication ranking those people by frequency or amount of communication;and a daily feed of the child's activities, organized to be sortablechronologically. The child's activities can comprise: any smart phoneapplications downloaded; content of any SMS text messages sent orreceived; identity of any websites visited; content of any socialnetwork posts created, viewed, or sent; and a visual warningincorporated into the daily feed. The visual warning can include one ormore (or each) of the following: cursing or bullying terms; questionablewebsite visits; and breaking curfew. The system can include thefollowing features: for each child, the parent portal can be furtherconfigured to display the following information on the same currentapplications screen: a list of all applications currently installed onthat child's phone, a visual warning identifying applications that areidentified as potentially harmful based on information in the analysisserver, and a description of the functions of each of the applicationsin the list. The system can also include the following features: foreach child, the parent portal can be configured to display the followinginformation on the same usage screen: a color chart indicating whichapplications were used by the child that day, and how much time wasspent using those applications. A system and apparatus for allowingparents to view and track smart phone activities of their children canalso include the following features: for each child, the parent portalcan be configured to display the following: text messages sent andreceived, with curse words and bullying terms highlighted; a list ofmost commonly used curse words and bullying terms; and an interfaceallowing a user of the parent portal to control if text conversationsshould be flagged automatically, and how many curse words or bullyingterms should be allowed before a flag is automatically applied.

A system and apparatus for allowing parents to view and track smartphone activities of their children can also include the followingfeatures: for each child, the parent portal can be configured to displaythe following web access information and controls: a whitelist mode thattriggers warnings if the child visits any website domain that is notlisted as specifically allowed; or a blacklist mode that triggerswarnings for only website domains that that are flagged by a user of theparent portal or by the existing database of harmful websites accessiblefrom the analysis server. A system and apparatus for allowing parents toview and track smart phone activities of their children can also includean embedded map feature visible in the parent portal that indicateswhere each child has traveled during the day and provides a warning ifthe child leaves a given geographical radius.

A system and apparatus for allowing parents to view and track smartphone activities of their children can also include a curfew featurecomprising: a control interface in the parent portal configured to allowa user of the parent portal to select restricted times that a child'ssmart phone may not be used; and an active restriction feature in thechild software module configured to completely disable the child smartphone during the restricted times, except for emergency phone calls.

A system and apparatus for allowing parents to view and track smartphone activities of their children can also include the followingfeatures: the parent portal can be further configured provide aninterface for receiving input from a parent, the input comprisingselections of which types of harmful material should be identified, andwhat level of scrutiny to apply in determining harmful material.

A system and apparatus for allowing parents to view and track smartphone activities of their children can also include the followingfeatures: a computer that periodically analyzes the selections from manyparents regarding types of harmful material and level of scrutiny,analyzes those selections statistically, and incorporates thestatistical results in setting default settings and recommendations forfuture users.

A system and apparatus for allowing parents to view and track smartphone activities of their children can also include an analysis serverconfigured to automatically identify patterns of harmful content forwhich helpful works of authorship have previously been created andstored in an electronic library, and provide immediate access to thoseworks of authorship to parents by transmitting an electronic copythereof or a link thereto to the parent portal for display adjacent to awarning based on harmful content that underlies those patterns ofharmful content.

A computing device can comprise: a communications module; a locationdetermining module; a memory device comprising a mobile safety modulestored thereon as computer-executable instructions; and a hardwareprocessor configured to implement the mobile safety module by executingthe computer-executable instructions. Implementation can occur by atleast accomplishing the following: retrieve computing device data fromthe computing device; send computing device data to a control system;and receive a command from the control system based in part on analysisof the sent computing device data. Computing device data can comprise atleast one of the following: receiving incoming messages using thecommunications module of the computing device; retrieving outgoingmessages sent using the communications module of the computing device;and determining a location of the computing device using the locationdetermining module. Computing can comprise one or more of the following:activating the location determining module; disabling the locationdetermining module; disabling the communications module; activating thecommunications module; and selectively deactivating one or more featuresof the computing device for a predetermined time period.

A system for monitoring one or more computing devices can comprise: amemory device comprising a controller module stored thereon ascomputer-executable instructions; a hardware processor configured toimplement the controller module by executing the computer-executableinstructions. These can be executed to at least: receive communicationsdata from one or more controlled computing devices; analyze receivedcommunications data; and transmit notification data to one or morecontrolling computing devices based on the received communications data.

A system for monitoring one or more computing devices can comprise: amemory device comprising a controller module stored thereon ascomputer-executable instructions; and a hardware processor configured toimplement the controller module by executing the computer-executableinstructions. This implementation can at least: receive location datafrom one or more controlled computing devices; analyze received locationdata; and transmit notification data to one or more controllingcomputing devices based on the received communications data.

A computing device can comprise: a communications module; a memorydevice comprising a mobile safety module stored thereon ascomputer-executable instructions; and a hardware processor configured toimplement the mobile safety module by executing the computer-executableinstructions. Implementation can at least: select notification settings;receive notification data based on the selected notification settings;and send command data to control an operation of a controlled computingdevice.

In some embodiments, a computing system can access one or more databasesin substantially real-time in response to input from a parent providedin an interactive user interface in order to determine informationrelated to a user system and provide the determined information to theparent in the interactive user interface. The computing system caninclude a network interface coupled to a data network for receiving andtransmitting one or more packet flows, a computer processor, and acomputer readable storage medium storing program instructions configuredfor execution by the computer processor in order to cause the computingsystem to generate user interface data for rendering the interactiveuser interface on a computing device, the interactive user interfaceincluding an indication of a first controlled device associated with afirst child of the parent, wherein the indication of the firstcontrolled device is selectable by the parent in order to initiateanalysis of usage pattern of the first controlled device and provideresults of the analysis to the parent in substantially real-time. Theprogrammed instructions can further include transmit the user interfacedata to the computing device. In some embodiments, the programmedinstructions can include receiving an identification of a selection bythe parent of a second controlled device associated with a second childof the parent in the interactive user interface. The programmedinstructions can also include accessing a database storing analysis datafor the second controlled device associated with the second child of theparent. Further, the programmed instructions can include updating theuser interface data such that the interactive user interface includesindications of at least a subset of determined high frequency contacts.The program instructions can include transmitting the updated userinterface data to the computing device.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments disclosed herein are described below with reference to thedrawings. The following drawings and the associated descriptions areprovided to illustrate embodiments of the present disclosure and do notlimit the scope of the claims.

FIG. 1 illustrates a computing environment including a safety systemthat can help deter cyberbullying.

FIG. 2 illustrates a communications monitoring process.

FIG. 3A shows views of a mobile application as it may appear running ona smart phone device.

FIG. 3B shows three views of a mobile application initiating and sign inprocess.

FIG. 3C shows four views of a mobile application sign in and settingsprocess.

FIG. 3D shows three views of a mobile application activation and deviceadministration process.

FIG. 3E shows four views of a mobile application setup process.

FIG. 3F shows two views of a mobile application protected status.

FIG. 3G shows two views that include a mobile application monitoringstatus.

FIG. 4 shows a view of a curfew lockout screen.

FIG. 5 shows a view of a website that can include a login screen for asystem user to access his or her account.

FIGS. 6A and 6B show a view of a web page that can provide subscriptionand pricing information.

FIG. 7 shows a view of a webpage that can assist a user in creating anaccount and providing name, e-mail, and password information.

FIG. 8 shows a view of a webpage that can assist a user in creating anaccount and providing billing information.

FIG. 9 shows a view of a webpage that can assist a user in preparing touse a safety system by downloading and installing the components.

FIG. 10A shows a dashboard view with a map.

FIG. 10B shows an explanation of some of the icons in FIG. 10A.

FIG. 11 shows a dashboard view with notifications information.

FIG. 12 shows a view of a notifications screen.

FIG. 13 shows a view of a device status screen.

FIG. 14 shows a view of an “Apps” screen.

FIG. 15 shows a Filters view of a set of SMS (or short message service)screens.

FIG. 16 shows an Activity view of a set of SMS screens.

FIG. 17 shows a WWW (or world-wide web) screen.

FIG. 18 shows a location screen.

FIG. 19 shows a curfew settings screen.

FIG. 20 shows an account information screen.

FIG. 21 shows a notification preferences screen.

FIG. 22 shows a devices screen listing the devices being tracked.

FIG. 23 shows a log-in screen.

FIG. 24 shows a user system including a notification (emphasized)received from the safety system over a network.

FIG. 25 illustrates a user interface including active links for parentsto access community features discussed above.

FIG. 26 illustrates user interfaces that enable users of the systemsdescribed herein to ask technical questions about the software includingsome or all modules of a safety system.

FIG. 27 illustrates an example a blog user interface generated by asafety system 110 to provide community features discussed above.

FIG. 28 shows a second portion of the user interface includingadditional articles.

FIG. 29 illustrates an embodiment of a user interface including anarticle or a blog.

FIG. 30 illustrates an example user interface showing a more detailedoverview of a professional listed in the blog roll.

FIGS. 31 and 32 illustrate example embodiments of a process for enablingsystems described herein on one or more user systems

FIG. 33 illustrates an embodiment of a maps user interface generated bya safety system to show location information of a child's user system ona map 3302.

FIG. 34 illustrates an embodiment of a notification administration userinterface 3400 generated by a safety system.

FIG. 35A illustrate an example user interface for activating a safetysystem on the computing device.

FIG. 35B illustrates an example user interface generated by a safetysystem 110 indicating status of a safety system on a particular usersystem 130.

FIG. 36 illustrates an example user interface generated by a safetysystem indicating that the user system is in curfew mode.

FIG. 37 illustrates an embodiment of a dashboard user interfacegenerated by a safety system.

FIG. 38 illustrates an embodiment of a process for generating adashboard user interface.

FIG. 39 illustrates another example view of a dashboard user interface.

FIG. 40 illustrates a photo/video summary user interface.

FIG. 41 illustrates a dashboard user interface that includes a contactssummary bar.

FIG. 42 includes a notification summary user interface generated by asafety system.

FIG. 43 illustrates an application usage interface.

FIG. 44 illustrates a current applications interface.

FIG. 45 illustrates an application installations interface.

FIG. 46 illustrates an embodiment of an SMS activity interface.

FIG. 47A illustrates an embodiment of an SMS filters interface.

FIG. 47B illustrates another embodiment of an SMS filters interface.

FIG. 47C illustrates search filters in the embodiment of SMS filtersinterface shown in FIG. 47B.

FIG. 47D illustrates an embodiment of an SMS analytics interface.

FIG. 48 illustrates a web access interface.

FIG. 49A illustrates an embodiment of a location interface.

FIG. 49B illustrates an embodiment of a location history interface.

FIGS. 49C-491 illustrate embodiments of location tracking interfaces.

FIG. 50A illustrates an embodiment of a curfew interface.

FIG. 50B illustrates another embodiment of a curfew interface.

FIG. 51 illustrates an embodiment of a master account user interface.

FIG. 52 illustrates another embodiment of an account user interface.

FIG. 53 illustrates another embodiment of an account user interface.

FIG. 54 illustrates a user system that can implement some functions of asafety system.

FIG. 55 illustrates using a remote computing system to track activitiesof a mobile device.

FIG. 56 illustrates an example sequence for detecting and listinginstalled applications on a device.

FIG. 57 illustrates an example sequence for web/browser filtering andapplication purchase restrictions.

FIG. 58 illustrates an example sequence for curfew or other time-basedblocking.

FIG. 59 illustrates a computing environment for monitoring activities ofa mobile device.

FIG. 60 illustrates an example process for flagging activities on aperson's mobile device.

FIGS. 61A, 61B, 62A, 62B, 63-65, 66A, 66B, and 67-72 depict example userinterfaces for a safety system.

FIG. 73 shows a generalized structure for a computer system that canperform functions described herein.

FIGS. 74-79 show example code excerpts.

DETAILED DESCRIPTION

Although certain preferred embodiments and examples are disclosed below,inventive subject matter extends beyond the, for example, specificallydisclosed embodiments to other alternative embodiments and/or uses andto modifications and equivalents thereof. Thus, the scope of any claimsappended hereto is not limited by any of the particular embodimentsdescribed below. For example, in any method or process disclosed herein,the acts or operations of the method or process may be performed in anysuitable sequence and are not necessarily limited to any particulardisclosed sequence. Various operations may be described as multiplediscrete operations in turn, in a manner that may be helpful inunderstanding certain embodiments; however, the order of descriptionshould not be construed to imply that these operations are orderdependent. Additionally, the structures, systems, and/or devicesdescribed herein may be embodied as integrated components or as separatecomponents. For purposes of comparing various embodiments, certainaspects and advantages of these embodiments are described. Notnecessarily all such aspects or advantages are achieved by anyparticular embodiment. Thus, for example, various embodiments may becarried out in a manner that achieves or optimizes one advantage orgroup of advantages as taught herein without necessarily achieving otheraspects or advantages as may also be taught or suggested herein.

Details regarding several illustrative embodiments for implementing thesystems and methods described herein are described below with referenceto the figures. At times, features of certain embodiments are describedbelow in accordance with that which will be understood or appreciated bya person of ordinary skill in the art to which the system and methoddescribed herein pertain.

The system and method described herein can advantageously be implementedusing computer software, hardware, firmware, or any combination ofsoftware, hardware, and firmware. In some embodiments, the system isimplemented as a number of software modules that comprise computerexecutable code for performing the functions described herein. In someembodiments, the computer-executable code is executed on one or moregeneral purpose or specialized computers. However, any module that canbe implemented using software to be executed on a general purpose orspecialized computer can also be implemented using a differentcombination of hardware, software, or firmware. For example, such amodule can be implemented completely in hardware using a combination ofintegrated circuits. Alternatively or additionally, such a module can beimplemented completely or partially using specialized computers designedto perform the particular functions described herein rather than bygeneral purpose computers. Similarly, a number of databases aredescribed herein. Any two or more databases can be combined into onedatabase and that any one database can be divided into multipledatabases. Multiple distributed computing devices can be substituted forany one computing device illustrated herein. In such distributedembodiments, the functions of the one computing device are distributedsuch that some functions are performed on each of the distributedcomputing devices.

The foregoing and other variations understood by a person of ordinaryskill in the art can be made to the embodiments described herein withoutdeparting from the inventions disclosed herein. With the understandingtherefore, that the described embodiments are illustrative and that theinvention is not limited to the described embodiments, certainembodiments are described below with reference to the drawings.

I. INTRODUCTION

More children now than ever before have access to mobile computingdevices (often smart phones), especially at an early age. Accordingly,phone safety is becoming increasingly more important for parents as theywant to monitor and control their children's activity on these devices.In addition, children also need protection from cyberbullying. Manystates have enacted cyberbullying laws. Cyberbullying is generallydefined as bullying that takes place using electronic technology.Electronic technology can include devices and equipment such as cellphones, computers, and tablets as well as communication tools includingsocial media sites, text messages, chat services, and websites. Phonesafety can also include reducing or preventing use of a phone whiledriving.

This disclosure describes embodiments of safety systems that can protectvulnerable mobile device users, in particular children. Safety systemscan assist parents in monitoring and controlling their children's mobiledevices, including, for example, the content stored on them or accessedby them, messages received and transmitted by them, etc. Parents cantrack location of the their children through mobile devices and set upvirtual location “fences” as described more in detail below. Safetysystems can mine data in text messages (or other communications),filter, and send reports to parents. In some embodiments, a report maybe sent to a law enforcement agency or other services, depending on thenature of the messages. Safety systems can also analyze non-writtencommunications, including pictures and videos.

The features of the systems and methods described herein can also beimplemented for mobile safety of groups other than children. Forexample, employers or caregivers may want to monitor or control mobiledevices of their employees or patients.

II. EXAMPLE GENERAL SYSTEM COMPONENTS

Web safety systems can include the following components that can worktogether or independently. First, an analysis engine that uses filtersand search logic. This can comprise a web based crawler and back-endlogic designed to continuously or periodically search, filter, or“crawl” social network accounts and flag conversations with illicitcontent (for example, undesirable content as may be defined ordetermined by a user). With respect to FIG. 1, one or more aspects ofsuch a crawler or back-end logic can be located on a server andaccessible through the web or a network 102, and the analysis engine canbe part of or accessible by the analysis module 112 of the safety system110. Such an analysis engine may also be at least partially included ina safety system plugin 132 that may be located on or close to a usersystem 130. The analysis engine or analysis module 112 can bedistributed between various processors, including one or more of thefollowing: a processor in a user system 130, a processor in the “cloud”or accessible from the network 102, a third party system 104, and/or aprocessor in a computer or device having access to a parent portal. Aparent can input user parameters 140 using a user system control module118 to help select and determine what the back-end logic or crawlerdelivers to the parent through a user interface module 116.

Second, a system can include a mobile application with various socialmonitoring and safety related features such as GPS/geolocation-basedmonitoring (for example, monitoring a child's location for safetypurposes), mobile web filtering/blocking, parental notification (forexample, alerts regarding keywords, new application installation,application usage, etc.), and SMS/Text message monitoring or blocking,call blocking, and/or phone lockout (for example, inhibition offunctionality while driving). In the context of FIG. 1, these functionscan be accomplished through a safety system plugin 132 that can beinstalled on a user system 130, for example. In some cases, raw data canbe gathered locally at a user system 130 (e.g., using a camera, a GPS, amicrophone, an accelerometer, from its memory, from other softwareapplications, etc.) and either partially processed by a safety systemplugin 132 or sent directly over the network using a communicationsmodule for analysis (or further analysis) by an analysis module 112 of asafety system 110. A safety system plugin 132 can be especially helpfulin controlling the local functionality of a user system 130.

Third, a website interface (for example, an administration portal, usercommunity, etc.) to allow users (for example, parents) to review reportsand details of protected individual's (for example, their children's)activities, subscribe or contribute to services such as crowd-sourcedwebsite black lists or white lists, and/or modify various parameters ofthe monitoring software. In the context of FIG. 1, this websiteinterface can be a user interface module 116 and/or an accountmanagement module 120, and it can be accessible via the network 102, forexample.

Fourth, back-end data hardware and software that can store, process,use, index, recall, and send (for example, for display) the informationfor use by the supporting systems for the functions listed above. In thecontext of FIG. 1, this back-end can be included in the analysis module112; it can be located remotely and accessible through the network 102;it may contribute the system parameters 150 and be administered by asystem administrator 108.

The described systems can incorporate and expand on the technicalinformation and teachings in U.S. Pat. No. 8,380,176; its entiredisclosure is incorporated by reference herein for all that it containsand is made part of this specification for all purposes.

III. EXAMPLE SAFETY SYSTEM

FIG. 1 illustrates an embodiment of a computing environment 100including a safety system 110 that can monitor and control a user system130. In some embodiments, a safety system is not limited to those itemsin the box 110 but also includes one or more of the other illustratedelements in the environment 100. For example, a server, a home computer,and a mobile device can act in concert, each having somelocally-installed software and communicating with each other through theweb or a network.

User system 130 is illustrated as a single item for convenience butrepresents one or more user systems 130. In general, the user systems130 can include any type of computing device capable of executing one ormore applications and/or accessing network resources. For example, theuser systems 130 can be one or more desktops, laptops, netbooks, tabletcomputers, smartphones, PDAs (personal digital assistants), servers,smartwatches, computerized eyewear, smart augmented-reality wear, e-bookreaders, video game platforms, television set-top boxes (or simply atelevision with computing capability), a kiosk, combinations of thesame, or the like. The user systems 130 can include software and/orhardware 132 for accessing the safety system 110, such as a browser orother client software (including an “app”). In some embodiments, some orall of the modules of the safety system 110 can be installed asapplication software on the user system 130.

The safety system 110 can control and/or monitor user systems 130 viaone or more modules of the user system 130. In a first example, the usersystems 130 can include a communication module (not shown) having anantenna for receiving and sending communications data. The user systemcontrol module 118 of the safety system 110 can block access to ordisable the communications module. Accordingly, the user system controlmodule 118 can prevent user systems 130 from transmitting or receivingcommunications.

In addition to using a communications module of a user system 130, theuser system control module 118 can also control the user system 130through various other technical channels. For example, even though thecontrol module 118 may monitor a communication module (e.g., as radiofrequency transmissions are prepared or transferred to or from anantenna within the user system 130), the control module 118 may use aseparate channel to exert control over the system 130. Thus, as a resultof monitored communications, a user interface may be controlled, locked,blocked, etc. Thus, passive monitoring and active control can berelatively independent as a technical matter, but the two functions canbe related through logic or programming within the safety system 110.This can allow greater flexibility in effectuating control and controlcan be asserted through multiple channels simultaneously or in acontingency arrangement. Thus, if a mobile phone user is able to defeatthe efforts of a control module 118 to control a communication module ofthe user system 130, the control module can revert to a mode thatinstead controls an interface of the system 130, thereby achieving thesame ultimate goal through a different technical channel. This controlredundancy can make the safety system 110 more robust because it candefeat efforts to circumvent its controls. That is, if a child attemptsto avoid parental controls in one channel, another channel may allow theparental controls to nevertheless prevail. Moreover, some operatingsystems may be more difficult to interface with. Accordingly, byallowing a safety system 110 to work through multiple channels tocontrol user systems 130, one or more of those channels may be morefeasible to implement as the safety system 110 is configured to workwith a more closely-guarded underlying operating system. Monitoring andcontrol directed by a user system control module 118 can occur at one ormore of the root level, a middle level, or a superficial level of a usersystem 130. In a second example of how a safety system 110 can controland/or monitor user systems 130, the user system control module 118 canintercept or otherwise access and analyze image or video feeds from orto the camera module of the user systems 130. For example, the analysismodule 112 of the safety system 110 can intercept and analyze livecapture of images or a video feed and determine whether it isappropriate for storage in the memory of the user system 130 or fortransmission. Based on the determination, the user system control module118 can block storage or transmission of the images or video feed. Thus,it can prevent, inhibit, deter, or monitor the taking or receivinginappropriate pictures.

In a third example of how a safety system 110 can control and/or monitoruser systems 130, the user system control module 118 can, in somecircumstances, turn on the camera module of the user system 110. Thismay be useful to identify the location of the user system 110 ordetermine if the child is in danger. The safety system 110 can use amicrophone of the user system 130 to receive an audio signal and furtherdetermine safety of the child based on parsing the audio. The safetysystem 110 can monitor for certain words (like “help”) or sounds (like“crying” or “screaming”). In some instances, the safety system 110 canuse the communications module of the user system 130 to send alerts (forexample, to parents or authorities) based on analyzed image, video, oraudio. The safety system 110 can use the speaker of the user system 130to output an alarm in an event of danger. In a fourth example of how asafety system 110 can control and/or monitor user systems 130, the usersystem control module 118 can receive information from a GPS moduleand/or an accelerometer module of the user system 130. Based on thereceived information, the user system control module 118 can identifythe location and/or calculate speed of the user system 130. In someembodiments, the analysis module 112 can supplement with accelerometerdata when the GPS data is not available to determine motion of the usersystem 130. In some embodiments, speed, acceleration, and/or relativelocation data can be collected, analyzed and/or used using theinformation in in U.S. Pat. No. 8,380,176; its entire disclosure isincorporated by reference herein for all that it contains and is madepart of this specification. Further, the speed may be monitored withrespect to other conditions for accuracy. For example, the safety system110 can measure heart rate of a user and track speed of the user deviceconcurrently to avoid false positives such as when the user isexercising or walking. The safety system 110 can also accessaccelerometer data from the user system 130 to determine that a personis running instead of driving.

The third and fourth examples provided above are examples of how asafety system 110 can control and/or monitor user systems 130. Thesedemonstrate how a mobile device can become a valuable tool to gather andpotentially transmitting information, acting as like an airliner's“black box,” a homing beacon, a child tracking device, and/or as adistress signal in various situations. In some modes, software on amobile phone can allow a child, for example, to activate a distresssignal that will record and/or transmit location information, sounds,pictures, etc. without alerting a would-be kidnapper to thetransmissions. To save battery, some embodiments may transmit suchemergency information in periodic spurts, for short amounts of time, toenable a longer emergency operation mode. Such an emergency mode can beactivated readily, or it can require a password or other verification toavoid improper or inadvertent uses. Thus, the systems described hereincan deter or assist in resolving not only cyber-bullying, but also helpremediate other more drastic and immediate physical dangers such askidnapping. In order to more effectively monitor and/or control aspectsof the user system 130, one or more software portions of the safetysystem 110 can be installed locally on the user system 130. For example,it may be inefficient to monitor radio transmissions, image or videofeeds, or location information remotely if the user system 130 is amobile device. Thus, the safety system can comprise an application thataccomplishes many monitoring and control functions locally, while stillaccepting input and control from a separate user system. Thus, a parentmay be able to log in to a user system control module 118 or accountmanagement module 120 and configure settings for the safety system 110,but those settings can be implemented through software or other modulesthat are locally present on a child's mobile device, which can be a usersystem 130. The safety system 110 can facilitate safe communication(e.g., through encryption) between the locally-installed software andthe web-accessible account management module 110 (which can act as aparental settings/monitoring portal). Thus, a parent may be able toselect and input user parameters 140, to decide levels of scrutiny andfiltering that should be applied to a child's device (which can be auser system 130).

In some embodiments, the safety system 110 can be integrated with thethird party tools through a plug-in or an API (application programminginterface). The third party tools may come pre-installed with a plug-into the safety system 110. In other embodiments, a plugin to the safetysystem 110 may be installed on to a third party tool. For example, athird party tool can include text/SMS client, an email client, a webbrowser, a social networking client (for example Facebook, Twitter,etc.), an image capture client, etc.

The safety system 110 can be implemented in computer hardware and/orsoftware. The safety system 110 can execute on one or more computingdevices, such as one or more physical server computers. Inimplementations where the safety system 110 is implemented on multipleservers, these servers can be co-located or can be geographicallyseparate (such as in separate data centers). In addition, the safetysystem 110 can be implemented in one or more virtual machines thatexecute on a physical server or group of servers. Further, the safetysystem 110 can be hosted in a cloud computing environment, such as inthe Amazon Web Services (AWS) Elastic Computer Cloud (EC2) or theMicrosoft® Windows® Azure Platform.

The user systems 130 can remotely access some or all of the safetysystem 110 on these servers through the network 102. The user systems130 can include thick or thin client software that can access the safetysystem 110 on the one or more servers through the network 102. Thenetwork 102 may be a local area network (LAN), a wide area network(WAN), such as the Internet, combinations of the same, or the like. Forexample, the network 102 can include any combination of associatedcomputer hardware, switches, etc. (for example, an organization'sprivate intranet, the public Internet, and/or a combination of thesame). In some embodiments, the user software on the user system 130 canbe browser software or other application software. The user system 130can access the safety system 110 through the browser software. Incertain embodiments, some or all of the safety system 110'sfunctionality can be implemented on the user systems 130.

A safety system plugin 132 can be part of a user system 130. This plugin132 can periodically communicate through a network 102 with a safetysystem 110 using, for example, a communications module of a user system130. This arrangement can allow for a safety system 110 to offloadintensive processing to a server rather than a user system 130 if thatsystem 130 is a smart phone, for example. Thus, if any filteringalgorithms, image analysis, etc. would tend to bog down a mobileprocessor or make the safety system 110 less transparent or moreintrusive to operation of a user system 130, this can be mitigated byinstead feeding raw data to a server or a home computer that is alsopart of or accessible by the safety system 110.

FIG. 1 shows various components of a computing environment 100. Anetwork 102 can facilitate communication between components of thesystem. For example, a system administrator 108 can use the network 102to confirm that safety systems 110 (e.g., as used and overseen byparents) are properly monitoring and controlling user systems 130 (e.g.,as used by their children). A system administrator 108 can also providesystem parameters 150 to the safety system 110. A safety system 110 caneffectively interpose its filters between a user system 130 and variousways in which that user system interacts with the world, whether throughany network 102 (including the world wide web) or otherwise. Thus, asafety system (in conjunction with parental interactions) can form aprotective shield for transmissions to or from a camera, acommunications module, a memory, a microphone, and/or a speaker of theuser system 130. Even the user systems 130 attempts to access thirdparty sites 106 or third party systems 104 can be monitored and/orcontrolled.

IV. USER SYSTEM MONITOR AND CONTROL

As described above, the safety system 110, which may include one or moremodules, can control and/or monitor the user systems 130. In someembodiments, the safety system 110 can monitor, filter, and/or blockcommunications.

A. Communications Monitoring, Filtering, Blocking, and Alerting

FIG. 2 illustrates an embodiment of a communication monitoring process200 for monitoring, filtering, and/or blocking communications sent orreceived at user systems 130. The communications monitoring process 200can be implemented by any of the system described above. Forillustrative purposes, the process 200 will be described as beingimplemented by components of the computing environment 100 of FIG. 1.The process 200 depicts an example overview of monitoring and filteringcommunications. In some embodiments, communications monitoring may alsobe implemented as described herein with respect to SMS Agent.

Any process descriptions, elements, or blocks in the flow diagramsdescribed herein and/or depicted in the attached figures should beunderstood as potentially representing modules, segments, or portions ofcode which include one or more executable instructions for implementingspecific logical functions or steps in the process. Alternateimplementations are included within the scope of the embodimentsdescribed herein in which elements or functions may be deleted, executedout of order from that shown or discussed, including substantiallyconcurrently or in reverse order, depending on the functionalityinvolved, as would be understood by those of ordinary skill in the art.

The process 200 (some or all of which can be cycled and repeated inparallel or serially) begins at block 202 when the communications moduleof the user system 130 receives or is in the process of sending acommunication. The communication may include, without limitation, atext/SMS message, a chat message, an audio message, a video message, amulti-media message (MMS), an e-mail, etc. The user systems controlsmodule 118 can intercept the communications. The communications can beintercepted using the following hardware and technical protocols, forexample. In some embodiments, the safety system 110 can capture packetsreceived at the communications module of the user system 130. The safetysystem 110 can detect whether these packets include messages, forexample, Whatsapp message, SnapChat messages, Facebook messages, etc.The intercepted messages can be stored in a data store 140 and analyzedas described herein.

These communications can then be analyzed by the analysis module 112 atstep 204. Some or all of this analysis can occur either onboard a usersystem 130, on a server accessible through the network 102, and/orwithin a safety system 110 that may be installed on a personal computerof a parent for example. The analysis module 112 can review the contentand source of the communications and determine, for example, whether thecommunications contain content that should be blocked or filtered, asindicated at step 206. This analysis can use external or internalsources (e.g., a dynamic dictionary of regional terminology,dictionaries of urban slang, a database maintained by a systemadministrator 108, one or more databases updatable by a community ofusers, specific language or country resources, etc.) against which tocompare this content. For example, the communication may contain illicitcontent such as profanity or inappropriate images. An analysis processcan include comparison of words and word groups to identify not onlyexplicit language but also aggressive language, explicit and implicitthreats, etc. Analysis can also review frequency (harassing ordistracting rapidity of test messages, for example) to determine if aperpetrator is hounding a child with frequent messages or transmissions.Analysis can review metadata for attachments to determine if they arenamed in a manner that indicates danger or indicates provenance from orassociation with pornographic websites for example. Communications canalso be analyzed to identify moods, such as neutral, or happy or sad ordepressing. Mood analysis can be a function of keyword search and/ormachine learning. Certain words such as “kill” or “depress” or “sad” canbe used to identify moods. The safety system 110 can generate alertsbased on the identified mood of the messages (or social mediacommunications) sent or received by the users. Accordingly, the safetysystem 110 can identify and trigger alerts for depression or suicide.Alerts may be received via postcard notifications on iOS or Androiddevices.

In an example, intercepted communications can be analyzed—and a safetysystem 110 can perform SMS filtering and searching to achieve the viewsshown in FIGS. 15, 16, 46, and/or 47, for example—using the followingtechnical protocols. In some embodiments, the safety system 110 can calloperating system hooks to access SMS messages or other social mediadata. Operating system hooks can include Android App Managers such asSMS Receiver. The safety system 110 can call these hooks over a periodictime interval. The safety system 110 can continuously monitor thecommunications, however, that might drain the battery of the user system110. Accordingly, the period may be balanced with respect to batterylife conditions. In some instances, the safety system 110 can poll fordata every 15 minutes. The safety system 110 can send polled data toserver for storage and analysis. In some embodiments, the safety system110 can capture video or snapshots of the display of the user device 130to track and analyze data. The safety system 110 can also modify theuser system 130 on the firmware level. Accordingly, in some instances,the safety system 110 can operate at a lower level than the operatingsystems to interface directly with the hardware modules.

The user system control module 118 can accordingly block or filter theintercepted communications (or take another alternative or additionalaction such as alerting a user) at step 208 based on the determinationfrom the analysis module 112. Blocking can include any one of thefollowing operations: not storing the communication in the user system'smemory, preventing the communications module from transmitting thecommunications, not showing the intercepted communications in the userinterface of the user system, deleting, responding with a message thatindicates the message was not received and the future messages will alsobe blocked, re-routing the message to another destination (such as aparent portal or school administrator), responding with anautomatically-generated kind and conciliatory message, automaticallyresponding with a reference to reporting, potential legal action, etc.Alerting a user can include passively recording events or items so thata user can look them up later, or it can include actively sending anotification message to a user. Filtering can include removing some orall content of the communication. In some embodiments, filtering caninclude substituting some content of the communication such as words(for example substituting the word “shucks” for the word “crap”).Certain images may also be blocked, redacted, censored and/orsubstituted. Filtering can include completely deleting harmful orbullying messages from a user system 130, and/or filtering can includere-routing those messages to a parent that may access the system througha user interface module 116.

In some embodiments, communications may be blocked or filtered dependingon the sender or recipient. Certain senders or recipients may be on ablock list. The block list may be created by users (for example,parents) through an administrative portal through an account managementmodule, for example. The block list may also be automatically createdbased on number of communications, frequency of communications, orinformation received from a third party system. For example, a systemcan include a web browser or an add-on to a web browser that includesits own blocking, alerting, and/or filtering functionality. Suchfunctionality can be accomplished through socket or port monitoring,proxy filtering or diversion, etc. Block lists can also be created andupdated centrally by a system administrator 108, for example. Blocklists can be maintained for various categories, allowing a user tosubscribe to filtering or blocking of a category of objectionable sitesor material, while allowing other material that may be objectionable tosome, but not that particular user. A multi-level hierarchy of blockingsensitivity can be created to allow a more trusted user to have accessto some information (e.g., medical information that may be blocked foryounger users due to anatomical references.) All examples of blocking orfiltering provided herein can additionally or alternatively comprisesending an alert or notification.

As shown at 210, an alert can be transmitted relating to an interceptedcommunication. The alert can take one or more forms, and can depend onthe result of the analysis 204. In some examples, the alert results inan objectionable word, phrase, or image appearing in a feed viewable bya parent and associated with the child, along with the sender of thatword or image. In some cases, a parent can view all communications withhis or her child, along with a breakdown of the people communicatingwith their child and the relative frequencies of those communications.

A safety system can be used to “trust but verify” (in the case whereblocking or filtering may be turned off in favor of active alerts orpassive logging). In certain embodiments, an alert relating to theintercepted communications can additionally or alternatively betransmitted to parents or a third party system. The safety system canalso store intercepted communications in a user data repository 140.Parents can review all intercepted communications from the user datarepository 140 using an administrative portal user interface describedmore in detail below.

Because an analysis and/or filter can be applied at various physicallocations—a child's device, a server, a parent's device, etc.—raw dataand/or alerts can be sent directly from a child's smart phone to aparent device, they can be sent from a server to a parent device, and/orthey can be sent within a parent's device. Timing of alerts isadvantageously rapid. Real-time alerts can be helpful to identifyharmful behavior rapidly and aid a timely response. Real-time can referto various relatively short delay periods, including a few seconds, oneor a few minutes, one or a few hours, same-day alerts, etc. Factors thataffect a delay before an alert (although that delay may not beinconsistent with real-time delivery) can include: internet connectionspeeds and availability, cell phone provider service, availableprocessor speed for analysis algorithms and technical protocols, andvarious application-specific factors.

In an example, various aspects of a child's device can be monitored andalerts or notifications can be provided to a parent. The general alertprocess can be accomplished using the following technical protocols. Forexample, alerts can be processed through a push protocol. The safetysystem 110 can analyze the monitored content and make a determination topush messages to the parent device. In some embodiments, the messagesmay be pushed according to a priority determination. For example,certain alerts relating to a child leaving a particular geofence may bepushed right away. Other alerts including child's usage of offensivewords may be sent in an email report or shown on a dashboard when theparent logs into the system. Accordingly, the safety system 110 candetermine priority levels of alerts and push them accordingly.

B. Application Monitoring, Filtering, Blocking, and Alerting

Similar to communications filtering, parents may also want to filtercontent from various software applications on the user systems 130, suchas web browser clients, social networking clients, SMS, MMS, etc. Thetechniques, protocols, principles, and approaches described elsewhere inthis application with respect to analyzing, filtering and blockingfunctionality can also apply here. In addition to restrictions onviewing content, the user systems 130 may be blocked from sendingmessages or posting content in some applications. For example, parentsmay want to be alerted to various activities, or to prohibit their kidsfrom posting pictures with alcohol or drugs on social networking sites.Parents may also want to be alerted or to prevent cyberbullying viasocial networking sites. Accordingly, the safety system 110 can crawlthrough social networking or other accounts of individuals to beprotected (for example, children). This may be done by configuring asafety system plugin 132 to track and automatically store the accountnames and passwords when children enter them for these websites or othersoftware applications. The safety system 110 can also work as a plug-infor these applications. The safety system 110 can review the content anddetermine any content to block or flag for review via the administrationportal or user interface module 116. In some embodiments, applicationmonitoring, filtering and blocking may also be implemented as describedherein with respect to Apps Agent.

In some embodiments, the safety system 130 can alert a user and/orprohibit, inhibit, or block downloading and installation of certainapplications. The safety system 130 can assess applications to beblocked using an application block list that may be defined by parentsor dynamically maintained by a system administrator 108 or a third partysystem 104, and be accessible to the safety system 110, which can accessand copy such a block list or comparison database periodically. Thesafety system 130, a system administrator 108, or others can dynamicallymaintain the app block list based on crowd-sourcing, allowing users ofthe system to give feedback about what applications should or should notbe included, or discriminating between various levels of protection in arefined hierarchy of block lists. The safety system 130 can useselections, reviews and/or ratings from a plurality of users todynamically maintain the app block list. In some embodiments, the safetysystem 130 can automatically send an alert or prepare a report when newapplications are installed on a user system. The reports may be sentdaily. Parents may also see these reports of the user system 130 on anadministrative portal. The report may include the application name, thedescription of the application, the date and time of installation, andapplication rating/reviews. In some embodiments, the safety system 110can remove an application from the user system 130 based on an input.For example, parents can remotely via the administrative portal selectremoval of a particular application from their child's phone.

Functionality related to application filtering and blocking can becontrolled from and/or reviewed using the interactive views illustratedin FIGS. 14, and 43-45, for example. In an example, a safety system 110can identify, analyze, uninstall, and/or block installation of softwareapplications on a user system 130 using the following technicalprotocols. For example, the safety system 110 can call an operatingsystem content provider to retrieve status of applications. The statusof the applications can include which applications are installed orremoved. The status can also include whether the application is activeor running in the background. Accordingly, the safety system 110 cancall operating system hooks to retrieve status of the applications. Insome embodiments, the data store 140 may partially reside in the memoryof the user system 130. The user system 130 may have restrictions onavailable data space. However, sending data continuously may tax batteryand bandwidth. Thus, in some embodiments, data is stored locally for acertain time period before being transferred to a server. For instance,data may be stored locally for 15 minutes before transfer to an externallocation. The local cache can be deleted after a predetermined timeperiod or once a predetermined capacity is reached.

C. Website Monitoring, Filtering, Blocking, and Alerting

The safety system can also block content from certain websites byfiltering or substitution. Some websites may be completely prohibited.Some approaches to filtering, blocking, and alerts can include creation,storage, and updating of one or more black lists or white lists. Theselists can comprise a look-up table that lists names, URLs, or otheridentifying indicia of the sites, sources, or content that will triggerthe relevant action. For example, a black list of undesirable websitescan be downloaded or accessible automatically by an application for amobile device. Black lists can be dynamically maintained by auser-community and various objectionable materials can be classifiedusing a code system (for example, “po” for pornography, “pr” forprofanity, “nu” for nudity, “vi” for violence, “dr” for drugs, etc.)Existing rating systems can be employed or expanded (for example, motionpicture or electronic gaming ratings can be used). Content can also beassigned a relative severity on a numeric scale, for example. Users canrate content and an average can be used to automatically include or notinclude certain content or websites in a black or white list. Users canthen determine their desired level of sensitivity and subscribe to oneor more sets of black lists or white lists. Black lists can also includegraphic images, for example of gang symbols, genitalia, other bodyparts, etc., and these can be used as reference libraries against whichto compare unlisted content with graphical algorithms. These conceptsrelating to user interaction, black lists, white lists, etc. can applyto blocking, filtering, and alerts with respect to both applications andweb pages, and message content. In some embodiments, website monitoringmay also be implemented as described herein with respect to WWW Agent.

In some embodiments, the monitoring, blocking, filtering, and/or alertfunctions described herein can be used to combat inefficient behavior bystudents and/or employees on the job. Thus, the system can not onlyimprove safety but it can deter time-wasting activities and improveproductivity.

In addition to analysis of web pages visited, URLs employed,applications run (remotely or locally), and messages sent or received,the system can scan stored files (such as website bookmarks, storedfavorites, etc.) in order to generate alerts or other blocking orfiltering activity. Some embodiments can allow removal of undesirablebookmarks, websites, etc. The system can employ key-logging, spy-bots,ad-ware techniques, etc. (techniques pioneered by more subversiveenterprises) in the service of the greater causes of improving safety,avoiding or recording evidence of illicit activities, cyber bullying,etc.

Functionality related to website or browser alerting, filtering andblocking can be controlled from, organized by, and/or reviewed using theinteractive interface illustrated in FIGS. 17 and/or 48, for example. Inan example, a safety system 110 can identify, analyze, inhibit accessto, send alerts related to, and/or block content from websites or otherinternet sources on a user system 130 using the following technicalprotocols. For example, the safety system 110 can poll content providerof the operation systems to retrieve URLs accessed by users. The contentproviders may access device drivers which may control hardware (such ascommunications control and GPS) of the user systems 130. Accordingly,the safety system 110 can poll respective content providers for specificinformation including telephony services, URLs, SMS, applicationmonitoring.

D. Safety System Plugin/Mobile Application

FIG. 3A illustrates views of an example safety system plugin (e.g., theplugin 132) that may be installed as a software application on a mobiledevice or smartphone (which can be a user system 130, for example). Anapplication can be downloaded to the smartphone, and the introductionview 310 can be shown upon launch of the application. Selection of the“how does this app work” button can result in the tutorial view 316,which can include multiple screens. Selection of the login button canresult in the log in view 318. Selection of the log in button after usercredentials have been entered can result in a current status view 320. Alog out control 322 can be provided, allowing entry of a password. Logout can be restricted to a parent or an account holder who installed themobile application and may not be available to any user of the mobiledevice.

FIG. 3B shows three views of an example mobile application initiationand sign in process. For example, a subscription reminder screen 332 canremind a user who has downloaded an application to subscribe and/orinstall additional software that will interact with the mobileapplication (or plugin 132). That additional software can provideanalysis and reporting features such as those described herein withrespect to safety system 110. An “OK” button control can allow a user toclose the reminder screen 332, and this can allow additional screens tobe viewed. One of the additional screens can be a sign in screen 334,which can have a sign in button and also provide information (and accessto further information, e.g., through a hyperlink or active controlillustrated here to say “How does WebSafety work” thereon) regarding thefeatures and usefulness of a safety system 110. Another additionalscreen can be a sign up screen 336, which can be web accessible andallow a user to obtain a subscription.

FIG. 3C shows four views of a mobile application sign in and settingsprocess. A password view 340 can include user accessible fields foraccepting and e-mail and password as shown. Alternatively othercredential systems can be used. For example, a user can access thesystem using credentials associated with a social network account. Thepassword view can accomplish functions similar to that of theintroduction view 310, for example. Clicking a sign in button canprovide a user access to a bifurcated user choice screen 344, allowing auser to choose who will use the device: a child or a parent. This canallow a single application software download that can function in eitherchild mode or parent mode, depending on a selection in a process asindicated here in FIG. 3C, and/or in FIGS. 31 and 32, for example.Selection of a “my child” control button can result in the my child view346; selection of a “parent/guardian” button can result in theparent/guardian view 348. Each option allows entry of a name, a savebutton, and a log out button. The my child option initiates a processthat protects the device and tracks its activity. The parent/guardianoption initiates a process that provides notifications to the device ofprotected services associated with children's devices on the sameaccount.

FIG. 3D shows three views of a mobile application activation and deviceadministration process. A protected view 350 can be seen on a child'sdevice indicating that a plugin 132 is installed and functioning. Anoptional activate button 351 can be selected, resulting in anadministrative information screen 354. A lock control 352 can beselected, resulting in a prompt to enter a password or other credential(see the access settings dialogue 374 of FIG. 3F), which, if provided,can lead to the bifurcated user choice screen 354. The administrativeinformation screen 354 can have an activate button 355, which, whenselected, can result in the curfew disable message screen 358.

FIG. 3E shows four views of a mobile application setup process. Forexample, setting up a child device (after choosing the option of “mychild,” see view 346) can include the technical process stepsillustrated here. These views can result after pressing an OK button asseen in the curfew disable message screen 358 and generally after thesequence shown in the views of FIG. 3D. A preparing SMS data view 360can indicate that the software is accessing, cataloguing, and/orotherwise preparing SMS data to be reported and formatted for a parentportal, for example. An uploading messages view 362 can indicated thatthe prepared data is being transferred to a server over the network 102.A syncing curfews view 364 can indicated that the software is adjustingcontrol functionality on the device shown here, and an uploading appsdata view 368 can indicate that the software is reviewing installedapplications and transferring that information to a server accessibleover a network 102. An analysis step (see analysis module 112, forexample) can then be performed by the server on any data uploaded to theserver.

FIG. 3F shows two views of a mobile application protected status. Thecurrently protected view 370 can result after the process shown anddescribed in FIG. 3E. As a result of that process, the “activate” button351 is not present in this view. The access settings dialogue 374 canappear when a lock control button 372 is selected, allowing a user toenter a password and change the settings, functionality, or role of thedevice (restarting a process described above, for example).

FIG. 3G shows two views that include a mobile application monitoringstatus. The parent/guardian view 348, shown again here, can be selectedand can result in the monitoring/notifications view 380. This canindicate that the device shown-which can be an example of a controlleruser system 130—is configured for use by a parent, because it is“currently providing notifications.”

E. Time Restrictions/Curfew Blocking

In some instances, the safety system 110 can enable parents to instituteelectronic curfew or grounding rules. Parents may want to ensure thattheir children cannot access certain features of the user system 130during a particular time of the day. Parents may not want their childrento text after 9 PM or they may not want children to access anyapplications on a phone after 10 PM on a school night. In someembodiments, the safety system 110 can allow selective applicationsbased on curfew settings. The selected applications can be customized byparents. For example, parents can allow certain educations apps duringcurfew time period. In some embodiments, curfews may depend on thelocation of the user systems 130. For example, schools may require allphones belonging to students to implement a curfew restriction on schoolproperty. The safety system 110 can identify that the user system 130 iswithin the property bounds of a school and automatically activateclassroom curfew restrictions. Accordingly, the safety system 110 cancustomize the user system 110 based on locations and/or curfew settings.The safety system 110 can accordingly block access to applications andcertain features of the user system 130 based on the curfew or groundingsettings. Parents may enter these settings via one of the userinterfaces described below. While the examples in this disclosure relateto children, these features may also be used by employers to controlaspect of employee's phone usage during work time. Employers may want todisable access to web browsing or social networking links from usersystems 130 during work hours. The safety system 110 can block theseapplications during a set time period or set locations. Employees may beable to access these application when they are away from work site.Similar functionality is also useful in a school setting. For example,an authorized and responsible school administrator may be able tooversee children's activities or limit use of smart phones. FIG. 4illustrates views of an example safety system plugin that may beinstalled as a software application on a mobile device or smartphone(which can be a user system 130, for example). When the plugin isinstalled and running, it can present a curfew lockout view 410 during adesignated curfew period. Selecting the “close” button 412 can result ina notification sent to the account holder (which may be a parent). Insome embodiments, a close button or similar functionality may not beprovided and a curfew lockout can be more strict and difficult to avoid,without having the password or other credential of the account holder. Anotification resulting from closure can be announced on the lockoutview, or it can happen in the background without including the text asshown. A logout control 450 can allow an account holder to stop thesoftware from running on the mobile device, for example. Another examplecurfew lockout screen is illustrated in FIG. 36. Lockout can involveinhibiting functionality of the operating system of a device at a rootor core level. Lockout can involve blocking user interfacefunctionality. Lockout can involve intercepting input or output at anintermediate level between these two approaches. In some embodiments,curfew restrictions may also be implemented as described herein withrespect to Curfew Agent.

Useful interfaces that can allow a parent to set curfew settings areincluded herewith as FIGS. 19, 50A, and 50B. As illustrated in FIG. 50B,the view can include a calendar background and allow visual blocks to bere-sized, dragged, or otherwise manipulated by the finger, cursor,mouse, or other user input approach. The blocks can represent time whenusage is allowed, or the blocks can represent time periods when usage isnot allowed. The size and placement of the blocks on the calendar, ascontrolled through a parent interface, for example, can establishperiods where smart phone usage of a child is not allowed. The softwareand system can be configured to actually prevent usage of the smartphone, or it can be configured to report any clandestine usage that iscontrary to the curfew restrictions. Curfews can be set as systemic,recurring calendar events, or they can be customized as a consequence ofspecific child behavior or failure to follow other rules orrestrictions. Incentives and punishments can be calibrated to correspondto varying curfew settings. Software installed on a smart phone can beemployed to track attempts to circumvent any curfew settings orrestrictions. Software installed on the smart phone can continue toreport some activities to a parental portal or other interface even whenthe smart phone itself is locked to prevent a child from using it duringa curfew period. The safety system 110 can also determine how long achild is on a particular application during the day and/or week andbased on the duration, enable some of the curfew restrictions. Also, asdiscussed herein, the safety system 110 can disable certain apps duringcurfew time. Further, as a child leave a particular area, the safetysystem can block some of the functionalities of the user system 130.

In an example, a safety system 110 can help establish time or curfewrestrictions on a user system 130 using the technical protocolsdescribed herein. For example, the safety system 110 can selectivelychoose which applications to enable in curfew mode.

F. Anti-Tampering

The safety system 110 can also track any attempts at tampering ordisabling features of the safety system 110. Children or employees maytry to remove the safety system 110 from the user system 130. The safetysystem 110 can attempt to block removal or disabling of its features.For example, the safety system 110 can be designed to send ping messagesthat may be encrypted over a network to verify that the safety system110 is still active on the user system 130. Anti-tampering functionalitycan also be achieved using redundant and/or parallel control techniques.For example, a user system control module 118 may control one or more ofthe following portions of a user system 130, for example: a centralprocessor, a communication module, a display, a memory, etc. In someembodiments, anti-tampering may also be implemented as described hereinwith respect to Apps Agent and/or Device Status Agent.

V. ANALYTICS

The safety system 110 can integrate or use other third party systems foranalytics. For example, the safety system 110 can integrate GoogleAnalytics to monitor usage of the mobile applications and website on auser system 130. The safety system 110 can store the usage stats andsend a report via the account management module 120.

VI. IMAGE ANALYSIS

The safety system 110 can intercept data being transferred to and/orfrom the camera on the phone. During video chatting (FaceTime, Skype,etc.), the system can perform image recognition and block any indecentcontent in real time or with a small or large time delay. The safetysystem 110 can also prevent storage of certain types of pictures ordrawings in the memory of the device. For example, the system canprevent the phone from storing any naked, violent, suggestive,inappropriate, or pornographic pictures taken via the phone's camera orreceived via external communications (for example text or data messagingapplications like SnapChat, WhatsApp, etc.).

Objectionable content can be identified using an algorithm that looksfor certain colors (flesh tones, etc.). Objectionable content can alsobe identified algorithmically by searching for or recognizing anatomicalfeatures in proportion or relation to others. For example, facialrecognition technology can be employed to identify a human face in agiven image. If a face is present, the image can then be reviewed todetermine the orientation of a human body associated with that face byfollowing common colors (for example, flesh tones) that may represent aneck. Orientation can also be determined by relative positions offeatures in the face; a body will generally be positioned in the samegeneral direction from the eyes that a mouth and chin are positioned,for example. This analysis can allow the algorithm to scan the areawhere a related human body is generally expected to be found, thusavoiding wasting computational and processing resources. A scan canreview images to identify erotic, suggestive, or otherwise inappropriateimagery by searching for contours, colors, lines, and/or shading thatmay be typically associated with images of breasts, genetalia, glutealregions, typical clothing that may be associated with only partial orotherwise suggestive coverage thereof, hands forming gang or other crudeor inappropriate gestures, etc. Images to be blocked, filtered, flagged,or analyzed can also be identified by metadata associated therewith, forexample data indicating provenance from a known pornographic website, an“xxx” indication, a title relating to sex acts, a name of a knownpornographic actor or actress, a word associated with erotic industries,etc.

In an example, a safety system 110 can perform image analysis to assistwith child safety and well-being on a user system 130 using thetechnical protocols described herein.

VII. PLACE ALERTS, RESTRICTIONS/GEOFENCING

Parents may want to track the location of their children or demarcate aphysical area on a map where their children should be or not be for aparticular time. As an example, parents may drop off their child at alocation such as a friend's house, a mall, or a movie theater. Whiledropping off a child, parents may select that location and choose aradius outside which a child should not stray. Parents may select thelocation via the administration module of the safety system 110.Selection may include checking the current location on a map.Accordingly, parents can create a geofence using the safety system 110.When the child leaves the area designated by the parent, the safetysystem 110 can send an alert to the parents. The safety system 110 canalso block certain features of the child's user system inside (forexample, disable Facebook inside of school geofence) or outside (forexample, texting outside of school during school time) of the selectedgeofenced area. Thus, parents may use the safety system 110 to monitorthe location of the child with the child's user system 130.

Parents can pre-designate location and/or time of where their childrenshould be during the day. For example, parents can set their children'sschool location. The phone safety system can then track the location ofthe child and send an alert to the parent when the child makes it to thedesignated location. An alert can also be sent when the child is movingoutside of the designated radius. Thus, if a child leaves the schoolzone during school time, an alert may be sent to the parents. A historyof phone location can also be tracked and recorded for later referenceand pattern recognition. In some embodiments, location monitoring mayalso be implemented as described herein with respect to Location Agent.

VIII. SPEED TRACKING

Tracking a moving phone can enable measurement of its speed. The safetysystem 110 can track location using the GPS module and accordinglycalculate an average speed of the user system 130 based on measuredlocations at certain time intervals. Other methods can also be used tomeasure the speed of a moving phone, such as, accelerometer ortriangulation. The safety system 110 can then inhibit some of thefunctionalities of the phone, for example, based on the detected speed.For example, if the phone is moving beyond a threshold speed, the phonesafety system can block incoming text messages, e-mails, multi-mediamessages, phone calls, etc. The safety system can also alert parents iftheir children are driving over the speed limit by automaticallyidentifying the speed limit (for example, based on the location of theuser system 130 over time, based on GPS or local cell-towertriangulation, based on independent accelerometer techniques, etc.).Such systems can incorporate and expand on the technical information andteachings in U.S. Pat. No. 8,380,176; its entire disclosure isincorporated by reference herein for all that it contains and is madepart of this specification.

Speed tracking may also be used to prevent, deter, or help deal moreeffectively with abduction. The safety system 110 can use variousinputs, including video, audio, and speed to identify a possibleabduction scenarios and send alerts to parents and authorities. As anexample, the safety system 110 can use variety of parameters to weightand determine an abduction score. Parameters can include screaming orcrying sounds, asking for help, unusual geographic location (not in theusual area the person is supposed to be), speed of the user system, orno phone usage for a certain period of time.

IX. PARENT PORTAL/USER INTERFACE MODULE

As described above, parents can select parameters using the accountmanagement module 120 and/or the user interface module 116 of the safetysystem 110. In some embodiment, parents can directly select the settingsfrom the child's phone. In some embodiments, parents can make thechanges remotely (to the child's phone) via one or more user interfacesdiscussed in more detail below.

A parent community portal (e.g., accessible through the user interfacemodule 116 or otherwise through a network 102) can increase theeffectiveness of the safety system 110 by enabling parents to shareinformation with the community. For example, parents can rate(positive/negative) software applications (“apps”), websites, etc. andthose ratings can be shared with other parents or users. The safetysystem 110 can look up the ratings and automatically decide whether toallow a child to access a particular application, or it can report thecommunity rating (along with voting percentages, detailed feedback,comments, etc.) to the parent for a final decision. Parent portal userinterfaces can show blocked messages and pictures to the parents andreceive their input, which can be used to adapt the system inblocking/reporting future messages and pictures. The account managementmodule 120 can learn parenting style and automatically implement changesbased on parent's selection of what is and is not appropriate, or aparent can actively select a level of protection or define their ownstyle using controls provided through a user interface module 116 or anaccount management module 120, for example. Such controls can includedrop-down menus listing available profiles, available blockingdatabases, available community standards resources, etc. The portal canalso use collected data from some or all parents or other users andperform statistical analysis to increase effectiveness of theapplication. Using appropriate permissions and safeguards (for example,removal of specific personal identifiers), some implementations canallow parents to see other parents' phone preferences for their childrenas a way to learning options and acceptable community standards incertain cultures and communities. In some embodiments, the safety system110 can enable parent to search community information from their usersystems 130. For example, the safety system 110 can provide a searchfunctionality to look-up apps of concerns and/or safety ratings.

X. AUTOMATED LEARNING ALERTS

As described above, the phone safety system can send alerts to theparents, employers, users, etc. Parents can decide if an alert is afalse positive and the system can adapt based on parents' ratings. Forexample, some parents might be fine with their child using the word‘stupid’, while other parents may not. Accordingly, technical solutionsinclude allowing a user to blacklist or whitelist their own terminologyusing a visual interface, dropdown menu, color scheme, machine learning,etc. The safety system 110 can store multiple categories of offensivewords. Categories may include firearms, sexual innuendos, etc. Thesafety system 110 can also use context to prevent false positives byanalyzing surrounding words and mood. For example, pattern may berecognized showing that a parent tending to be more strict regardingsome words is also more likely to be more strict with regard to otherwords. User community data can be analyzed in order to save a parenttime in designating all objectionable words and instead implementing apredicted level of tolerance based on an initial set of responses to aninteractive survey or other settings. Also, in some cases there might belanguage/cultural misunderstanding. As described above, the safetysystem 110 can learn parents' responses to the alerts.

Integration with existing public systems and institutions can bebeneficial and more easily achieved when an automated system such asthose described herein are deployed. For example, suspicious text andmessages indicating cyberbullying may automatically be sent to a policeor a school server for further investigation. A parent can beautomatically queried prior to such notifications to authorities, ornotified simultaneously.

XI. EXAMPLE BENEFITS

Systems and methods described herein can accomplish automatically whateven tech-savvy parents can't. Thus, no matter how attentive, a highlytechnical parent likely does not have time to scan logs or usertransmissions (both content and timing) coming to and from their child'sdevice(s). Children may be sending more than 100 text messages a day andin addition may be posting on different platforms and network. Moreover,writing a script to perform such tasks may be beyond the skills of eventech savvy parents, especially when dangerous applications areconstantly being created and distributed. Children maybe likely todelete messages before parents are able to review them. The safetysystem 110 can include one or more modules described above that canretrieve and analyze messages (including texts and data messages) beforea child has an opportunity to delete the messages from their computingdevices. For example, in some embodiments, the safety system 110 canretrieve messages from memory of the phone in real time or insubstantial real time with respect to messages sent and/or received.Thus, even if a child is using applications like SnapChat, the safetysystem 110 can retrieve sent and or received messages before they aredeleted from the phone. In some embodiments, a system can periodicallyor continuously record screenshots or screen-capture video during thetime that a problem website or application is being used on a usersystem 130. This recording function can be used as an alternative oradditional measure if the website or application is not blocked orremoved, for example. This function can also be used to gather evidenceagainst a cyber-bully or other perpetrator who attempts to destroyevidence or mask harmful activities using electronic means.

In an example, a safety system 110 can perform image capture andfrequent logging of screenshots to assist with child safety andwell-being on a user system 130 using the technical protocols describedherein.

Thus, the systems described herein can protect the lives and well-beingof children. Monitoring of devices (for example, Android, iOS, or otherdevices that are examples of user systems 130) can be accomplishedremotely by parents using tablets, laptops or home computers (which canprovide a parent access to the safety system 110). The systems describedherein pay attention to children's behavior on their smartphones andtablets so users can be a parent, even in their world—that is, even whenfast-evolving modern technology and social systems are being used bychildren on a constantly evolving basis. These systems can providesimple, real-time notifications that bring vulgar, derogatory andsuspicious online behavior to a user's attention so parents have theopportunity to react when it matters. These systems can provide alertsto potential cyberbullying—which can be purely electronic, or aprecursor or adjunct to physical bullying. These systems give parentsthe opportunity to open a sensitive and timely dialogue with childrenchild about the challenges they may be facing. The systems describedherein can do what caring parents can't, due to technologicalimpediments and time constraints. Thus, the described systems empowerusers with awareness by monitoring children's smartphone and tabletactivity including internet, social media, and texting, so parents canteach and assist their children, for example.

XII. EXAMPLE OVERVIEW

An example system can protect one or more devices (e.g., a user system130) using a monitor dashboard (e.g., a user interface module 116 and/oran account management module 120) and notifications. Systems and methodssuch as those presented herein can allow parents (or any users, butgeneralized users can be referred to as “parents” herein) to protectmultiple devices (e.g., user systems 130) such as tablets and phones.Parents can customize the alerts and other information they wish toreceive about their child's social communications and behavior. Thus, asingle responsible user can have a device or web interface that tracksinformation sent by or received by one or more other devices (e.g., usersystems 130) that are used by those over whom the responsible user hasparental or other authority for safety and well-being.

To accomplish these goals of safety and well-being, a responsible usercan have access to a “monitor dashboard,” which is an example of a userinterface module 116 and/or an account management module as illustratedwith respect to the safety system 110 of FIG. 1. This can be a webportal, accessible from any computer over the world-wide web (see thenetwork 102 of FIG. 1); it can be an application accessible on aparent's own mobile device. The dashboard (which can be made availablevia the user interface module 116 of FIG. 1, for example) can be awindow that allows parents to see what is going on in their children'slives in real time, and recognize potentially harmful communications(and/or other activities, location, viewing and usage habits, etc.)before it is too late. Examples of how such a dashboard can be arrangedand visually presented are provided herein.

Organization of information in a dashboard view can be highly effectivein making a monitoring application effective. A dashboard can allow atleast some portion of various data resources to be visible at the sametime, but allow a single interactive view from which more details can beaccessed for any of those data resources. The portion viewable in thedashboard view can provide decision-making information that helps a userassess whether the additional details should be accessed. For example, adashboard can include information about how many “alerts” have occurredsince the last time details were viewed. Additional disclosure on theseand related topics are provided herein with respect to many of thefigures. It can be helpful to organize notifications and contentaccording to which child's device is the source of a notification.

It can also be helpful to organize notifications according to perceivedpriority or threat level. Default presumed threat levels can beestablished in the system. In some cases, a parent/user may establishtheir own hierarchy of priorities for notifications. Higher threats ormore urgent priorities can be listed or displayed more prominently,and/or they can lead to more drastic notifications. For example, athreat of physical harm may cause a monitor dashboard to proactivelysend a text or other message to a parent's phone, using the audio aspectof a ringing phone to alert a parent to imminent danger for a child. Totake another example, receipt of a crude or otherwise inappropriateimage, or receipt of anything at all from a designated threat source,can give rise to visual, tactile, haptic, audio, or other feedback,either through or facilitated by a monitor dashboard. Notifications canbe provided as real-time alerts, giving parents the opportunity tobecome aware of cyberbullying and inappropriate behavior, in a timelymanner.

A monitor dashboard (e.g., a user interface module 116) can depend oninformation fed to it from sources that continuously or periodicallymonitor and access content on a child's device. This can be accomplishedthrough software that is installed on a child's device (e.g., a safetysystem plugin 132) or otherwise has access to—for example, through acellular network or data-provider's servers—information coming to andleaving from a child's device. That software (or a server accessibletherefrom via a network 102) can automatically translate thesecommunications and parse or otherwise analyze them to identify whatportions of these communications involve actual content sent to or froma child. Such parsing can increase efficiency when transmitted datavolume is high by ignoring some aspects of headers or other technicaltrappings and focusing instead on substantive content (for example, theactual text of an SMS, the actual images attached to an e-mail ordelivered through a snap-chat type platform, etc.) Monitoring softwarecan be periodically updated to support monitoring of applications deemedto be new threat sources. Thus, periodic updating and interaction with aremote server can be very helpful to improve effectiveness of suchmonitoring software.

XIII EXAMPLE SYSTEM FEATURES

Beneficial features of a system can include one or more of the followingfeatures: (1) a dashboard such as that discussed above. This can be areal-time dashboard that parents can use to stay informed on the mobilephone and tablet usage habits of their children. “Real time” canindicate that updates or notifications can occur on a time scale that isrelatively rapid with respect to some other underlying time scale, itcan refer to virtually instantaneous updates, or it can refer to updatesthat occur within seconds or minutes. (2) Ability to monitorapplications, or “apps.” Thus, a parent can be notified of installedapps on a child's phone or tablet. To assist users who may not befamiliar with the latest applications, detailed descriptions can beprovided of the leading applications on a child's phone and why a parentshould or should not be concerned. (3) Ability to monitor text messages,for example those provided through a short message service (“SMS”).Thus, a parent may have the ability to view all the SMS messages sentand received by their child's device, with the ability to receivenotifications when words of concern are used. Parents can also benotified when flagged contacts (that is, contacts of a child that havepreviously been identified as a potential problem or threat source) sendsomething to the child (for example, an SMS message). (4) Ability tomonitor browsing or other usage of the world-wide web (“WWW,” or “web”).Parents can receive alerts when flagged URLs such as porn and otherinappropriate websites are accessed from a child's device. (5) Abilityto monitor social media. A parent may be able to view photos uploaded toa child's Social Media accounts in one convenient location, and receivealerts when content (for example, words, music, or images) of concernare used on social networks. (6) Location Tracking. Parents can viewcurrent and past locations of their child's device, and create areas(geo-fences) where the child cannot use their phone (i.e. school) or theparent will be notified. Geo-fencing features can provide exceptions foremergencies. Such exceptions can be accomplished through a permissionsystem involving a parent's remote decision through a dashboard, forexample. Another example is an ability to telephone a parentnotwithstanding a geo-fence blocking all other calls from a particularlocation. (7) Curfew. Parents can establish time restrictions on whenthe child can use their mobile devices. For example, if the child triesto use the device during restricted times, the parent can be notifiedimmediately. Exceptions for emergencies can also be implemented here.(8) Notifications. All notifications or alerts can be set to real time,hourly, daily, or weekly summary reports. Notifications can beaccompanied by icons or particular colors indicating a level of priorityor urgency. They can also include icons indicating that the source of anotification is a software program such as those with one or morefunctions described herein.

XIV. EXAMPLE USER INTERFACES

FIGS. 5-23 show example views of hardware running software that canaccomplish the goals discussed herein. These views and the included textand graphical placement indicate functionality and features of a websafety system.

FIG. 5 shows a view of a website that can include a login screen for asystem user to access his or her account.

FIGS. 6A and 6B show a view of a web page that can provide subscriptionand pricing information.

FIG. 7 shows a view of a webpage that can assist a user in creating anaccount and providing name, e-mail, and password information.

FIG. 8 shows a view of a webpage that can assist a user in creating anaccount and providing billing information.

FIG. 9 shows a view of a webpage that can assist a user in preparing touse a safety system by downloading and installing the components. Asnoted in FIG. 9, three steps for initiating use of a safety system 110can include downloading a software application (“the App,” or a safetysystem plugin 132) to a mobile device (e.g., a user device 130), settingup a parent device (to display or access the user interface module 116,to receive notifications from the safety system 110, etc., installing aplugin 132 that may be configured for parental use), and setting up achild device (providing user parameters 140, installing a plugin 132that may be configured for a use on a child's device, granting thatplugin access to various portions of the user system 130, etc.) FIG. 31shows a screen indicating example steps, processes, and screen shots forsetting up a parental device. FIG. 32 shows a screen indicating examplesteps, processes, and screen shots for setting up a child device.

XV. WEBSAFETY SOFTWARE EXAMPLE, WITH INTERFACE VIEWS

In addition to the figures included herewith and described herein,reference is made to U.S. design patent application No. 29/509,071,which provides additional interface views, examples of how informationcan be viewed, and views of controls allowing users to interact with acomputer through a user interface. The entire disclosure of this designapplication is incorporated by reference herein for all that it containsand is made part of this specification.

FIGS. 10A and 33-53, among others, show various views of a softwareframework for presenting information and controls to an account holderfor a system such as the ones described herein. Many of these views areexamples of how a user interface module 116 of FIG. 1 can beimplemented. At the left in these figures is a vertical series of tabswith icons that may allow a user to touch, click, or otherwise selectthem. Each tab causes a different view (or set of views) to be presentedto a user, and examples of those views are presented below. Some ofthese tabs have sub-tabs that may appear, for example, immediately tothe right of the left-most series of tabs. The tabs shown here aremerely examples, but they include (as noted in FIG. 10A): Dashboard 1010(which may include Account Info and Notifications sub-tabs, forexample), Device Status 1012, Apps 1014, SMS 1016, WWW 1018, Location1020, and/or Curfew 1022.

FIG. 10A shows an embodiment of a dashboard user interface 1000 with amap 1002 indicating the current location of devices subject to thesystem, the names of the children using the devices, a status section1006 including an SMS status, a world-wide web status, and the time of alast update 1004. This view also shows a list of the latestnotifications 1008. The latest notifications can include messages to auser alerting them to the actions of their children with respect totheir user systems 130, for example, and the times at which theyoccurred. FIG. 10A can indicate a view that is provided by userinterface module 116 of FIG. 1. Live hyperlinks can be provided. Forexample, clicking on the name “Billy” can load a device status screenfor Billy. Clicking on “view” in the notification list can load an SMSactivity screen with an SMS conversation visible. The dashboard view canbe accessed, for example, by an account user on a computer or anothermobile device. FIG. 37 provides another software interface view of adashboard.

FIG. 10B shows an explanation of some of the icons in FIG. 10A. Iconsare provided showing data connection 1030 (when the icon is darker ormore prominently displayed, a data connection is available, as indicatedby the up and down arrows for uploading and downloading), GPS data 1032(when the icon is darker or more prominently displayed, GPS data isavailable for the device), curfew 1034 (when the icon is darker or moreprominently displayed, it can indicate that a curfew lockout has or hasnot been bypassed), and device status 1036 (when the icon is darker ormore prominently displayed, it can indicate that device status has orhas not changed).

FIG. 11 shows a dashboard view that emphasizes and explains notificationfunctionality of an example system. In the notification bar at the topright, a notifications call-out window 1110 can be displayed afterclicking the notification icon 112. A “view all notifications” hyperlinkcan be selected to show a “notifications” screen. Other icons in thenotification bar at the top include a gear 1114 that can allow a user toaccess a settings interactive interface.

FIGS. 11-22 and 37-53 (among others) illustrate how the disclosedsystems, apparatus, and methods can automatically extract and assembledata from complex, moving electronic devices and assemble that data inorganized and graphically efficient views. For example, the dashboardviews of FIG. 11 can show locations of two different children on thesame map at the same time in the same view. The embodiment of FIG. 11also aggregates data relating to both of the children and their smartphones—the status of both Billy's phone and Jenny's phone is shown inthe same view. The notifications listing also assembles events andmessages from both children and integrates them chronologically. Thus,this graphical display allows efficient review by a user of a parentportal. The dashboard assembles data in a highly organized and efficientmanner.

FIG. 12 shows a view of an example notifications screen that can providea continuously scrolling list, where the most recent notifications canbe included most prominently (for example, on top of the list orotherwise emphasized). These notifications can be accessed from variousother interface views in the system—see, e.g., FIGS. 37,39, and 41 thatshow “alerts,” which can be notifications—many of which can present ashorter list of only the latest or most relevant notifications, but withthe ability to click through to this more extensive list. Another viewof a notifications page having similar functionality is provided as FIG.42.

FIG. 13 shows a view of a device status screen that may present a moredetailed or dedicated view that is related to or accessible from thedevice status portion 1006 of the dashboard described in FIG. 10A. Inthis example, it is Billy's device status that is displayed, and thetable indicates that Billy's device (a user system 130 in the context ofFIG. 1) has WebSafety software installed (which can fill the role of asafety system plugin 132 in the context of FIG. 1), the device GlobalPositioning System (GPS) is on, the data connection (for example,through a cellular phone network) is on, and that the device itself ispowered on. Other device status information views are provided asportions of FIGS. 41 and 51.

In an example, a safety system 110 can identify and report on devicestatus (e.g., installation of a safety application or plugin, GPSstatus, data connection, and/or whether a user system 130 is powered on)using the technical protocols described herein. In one embodiment, thesafety system 110 can call on operating system modules such as contentproviders (for Android OS) to access device status. In some embodiments,device status monitoring may also be implemented as described hereinwith respect to Device Status Agent.

FIG. 14 shows a view of an “Apps” screen, including “Apps ofConcern”—for example, mobile device applications that can potentially beused in cyberbullying activities. In some embodiments, a system canblock, delete, or otherwise deter use or functionality of one or more ofsuch applications. Application usage can be tracked and reported asshown. For example, an “Apps of Concern” portion can list softwareapplications that have been identified as presenting potential dangersto children, their installation dates, and when they were uninstalled,if applicable. Columns in the tables can be sorted by each column byclicking the header, then the arrow. Uninstalled applications can beshown in a lighter font color, or “grayed out.” A calendar 1412 showingapplication usage organized by date in a table 1414 can initially showthe current day as a default view. Other views related to softwareapplications (including control panels from which a user can updatecontrols, filters, and gather information) are provided as portions ofFIGS. 43, 44, 45 and 48. FIG. 15 shows a Filters view of a set of SMSscreens. In some embodiments, a system can identify cyberbullying basedon frequency of received communications. A system can search for orfilter words that may be employed by users of short message servicefunctionality. This view shows a search filter list 1512, where searchresults can be shown automatically as a user of this view types in asearch term. The system can also automatically block senders that mayuse more than a given number of filtered words, as shown at 1516. Userscan also be unblocked, as indicated by the hyperlinks of the words“Unblock” at 1520. Word usage frequency can be tracked, as shown underthe heading “Usage Top 20” at 1526.

FIG. 16 shows an Activity view of a set of SMS screens. Thisdemonstrates how information can be grouped and collected for efficientviewing, through interaction of a user with controls made availablethrough a user interface. The “filters” portion 1530 of the userinterface illustrated in both FIGS. 15 and 16 can be selected by a userto access the controls and information visible in FIG. 15. Immediatelyadjacent to the filters portion 1530 is an “activity” portion 1534 ofthe same toolbar. Selecting the activity portion 1534 can control theview to provide a running timeline view of messages sent and received,as shown. A control can be provided (shown here as check-box 1620)allowing a user to decide, upon review, that a particular person shouldbe blocked and immediately and conveniently block that person fromconversing with their child through texts. FIGS. 15 and 16 illustratehow a series of graphical controls and selections can be used toorganize and allow a user to access information. Thus, a hierarchy ofselections can include selection of an “SMS” control in a first controlarea (the left-hand bar), selection of a particular child (here, Billy)in a second control area, selection of filters or activity in a thirdcontrol area, and, in FIG. 16, selection of a particular interlocutor(here, Jacob) in a fourth control area. All four control areas can bevisible simultaneously to allow rapid changes between the informationvisible and the controls accessible for selection. Additional controlareas can be included (and indeed, various selectable portions of thescreens shown in FIGS. 15 and 16 can be characterized as additionalcontrol areas, including the tool bar visible across the top of theviews shown here.

Messages with filtered words can be highlighted (e.g., using a differenttext or background color such as red) or otherwise identified ordistinguished in order to draw the attention of a user. A “filteredword” can be a word that appears in a black list or a block list, andcan be a vulgarity or epithet, for example. Thus, “filtering” can referto searching for forbidden or problem words, or it can refer to allowingsome words to pass while blocking others. This selection can also revealfurther selectable controls specific to various potential SMSinterlocutors with whom a child may converse through texts, as shown inthe sidebar listing names. Various SMS senders can be listed (as shownat 1612 with the example list of names: Jacob, Sophia, Mason, Emma,Ethan, and Isabella). At 1616, search results may be shown (this may beaccomplished on the fly as search terms are entered without a userneeding to refresh a page). Clicking on the hyperlinked text “go toconversation” can display a message in context in the center of thewindow. Other views related to SMS filtering that may provide similarfunctionality to that described with respect to FIGS. 15 and 16 areprovided as FIGS. 46 and 47. FIG. 17 shows a WWW (or world-wide web)screen, indicating that blocking mode can have a blacklist and awhitelist for URLs to block or allow. An “X” can indicate a website isblocked, and a check-mark can indicate that a website is allowed. Aswith various other views illustrated and discussed herein, variousportions of this view are “active” in the sense that a user can interactwith them to select options, activate functions, and generally controland interact with the safety system 110. Thus, the blacklist andwhitelist modes can be selected by the blocking mode user controls 1712,and particular URLs can be blocked or allowed (or flagged or allowed) bya user toggling between these options using the URL-specific usercontrols 1716. A user can customize a blacklist or whitelist by typing aURL into the customization field 1720, which invites input using thefaint text “Add site.” Further actions are indicated in the active area1724, using an eye icon (which can allow a parent to link directly to abrowser view of the URL in question to research whether it should beincluded), a pencil icon (which can allow a parent to edit the fieldlisting the URL or to add notes annotating when or why a site wasincluded, for example), and a trash can icon (which can allow a URL tobe removed from the list, for example). Thus, a user can effectivelycontrol the filters and the functionality of the safety system 110 inorder to customize it for the needs of their family. Other views relatedto web access that may provide similar functionality to that describedwith respect to FIG. 17 is provided as FIG. 48. FIG. 18 shows a locationscreen indicating at the location box 1812 example user Billy's locationon a map, along with the date and time that the location was recorded.As indicated in the edit device menu 1820, different colors can be usedfor different devices and users being tracked. Here, Billy's device isshown on the map with light blue icons. An eye icon can be selected toshow or hide a device on the map, or to otherwise view relatedinformation, re-orient the map, or otherwise draw attention to or makemore accessible some aspect of Billy's location data. A frequency can beselected for how often to search for or display device locations, asindicated with the illustrated edit device menu 1820. A location historycan also be provided and accessed from this location screen, for exampleby selecting a data from the calendar 1824. Location information can begraphically or otherwise juxtaposed to aid a parent in recognizingpatterns and/or deviations therefrom. This location screen or a similarinteractive view can be used to establish geographical boundaries and/orother geofencing functionality. For example, a circle can be dynamicallydrawn or placed on the map indicating an allowed radius of unreportedmovement within which the phone (or a safety system plugin 132 of a usersystem 130) need not alert a parent. Other shapes can be drawn, whichcan relate to school campus boundaries, allowed neighborhoods,prohibited locations, no-go zones, etc. Results of violating borders canbe reporting, diminishing smart phone functionality (e.g., limiting toonly emergency calls and abduction tracking, etc.) Other views relatedto location tracking that may provide similar functionality to thatdescribed with respect to FIG. 18 are provided as one or more portionsof FIGS. 33, 37, 39, 41, and 49.

FIG. 19 shows a curfew screen indicating Billy's curfews for variousdays of the week, including start times 1914, stop times 1915, and checkboxes 1916 for when to apply the curfew, for example. The illustratedinterface is interactive and provides an array of customizable controlsand active fields that can be adjusted and edited by a user. Forexample, an active field or hyperlink 1912 can be used for addingadditional time restrictions. Check-boxes 1916 can be selected for whichdays of the week the curfew time restrictions should be applied. Agarbage-can icon 1918 can be used for deleting a given restriction,which may result in the delete menu 1920; this menu may include aconfirmation (for example, typing the word “delete” as indicated,providing some other control input such as a password, etc.). A penciland paper icon 1922 can be selected to edit restrictions, which mayresult in the edit menu 1924, as shown, with its additional interactivefields and controls. The delete menu 1920 and the edit menu 1924 can betypically not shown, except when one of the icons 1918 or 1922 isselected. Other views related to curfew information and controls thatmay provide similar functionality to that described with respect to FIG.19 are provided as one or more portions of FIGS. 50A and 50B.

FIG. 20 shows an account information screen 2010. In the context of asafety system 110, this screen can be interactive and represent a way ofinteracting with an account management module 120 (see FIG. 1) through auser interface module 116. An initial view of an account informationscreen 2010 can include information provided during an account setupprocess (see, e.g., FIGS. 7 and 8), but the fields 2020 can allow a userto update the information and save new information relating to billingand so forth.

FIG. 21 shows a notification preferences screen 2110. An account usercan indicate the email address or addresses to be used for notificationsas indicated at 2120; multiple emails can be listed. Other notificationapproaches can also or alternatively be used, including texts, phonecalls, audible notifications, some combination of these options, etc.Alerts can be sent to an account user when: an SMS filtered word is sentor received (for example, via SMS or multimedia (MM)), or if the usercontacts a selected (“filtered”) number; a user tries to access afiltered URL; a user closes the curfew screen; a GPS functionality of adevice is disabled or re-enabled; a data connection to the device islost; and/or account changes are made. Other notifications can also beprovided. The selections made when initially setting up a child's device(as explained herein with respect to FIG. 9, for example) can beinitially displayed here, but interactive controls can be providedallowing a user to update or otherwise change the settings andconfiguration. Another view related to notification preferences andcontrols that may provide similar functionality to that described withrespect to FIG. 21 is provided as one or more portions of FIGS. 34 and53.

FIG. 22 shows a devices screen 2210 listing the devices being tracked inan example account. Billy has an HTC One, and Jenny has a Samsung GalaxyS4. Installation of software (which can play the role of a safety systemplugin 132 of FIG. 1, for example, “WebSafety,” available fromWebSafety, Inc. of Newport Beach, Calif. as of October 2014 and itssuccessors) and logging in to the account from that software on a usersystem 130 which can be the devices listed above can cause a device toautomatically be visible in the list. Devices' association with usernames (for example, Billy is associated with HTC One) can be edited, anddevices can be deleted from the listing as shown. For example, agarbage-can icon 2218 can be used for deleting a given device, which mayresult in the delete device menu 2220; this menu may include aconfirmation (for example, typing the word “delete” as indicated,providing some other control input such as a password, etc.). A penciland paper icon 2222 can be selected to edit a device, which may resultin the edit device menu 2224, as shown, with its additional interactivefields and controls. The delete device menu 2220 and the edit devicemenu 2224 can be typically not shown, except when one of the icons 2218or 2222 is selected. Another view related to devices to track andmonitor and controls that may provide similar functionality to thatdescribed with respect to FIG. 22 is provided as one or more portions ofFIG. 51.

FIG. 23 shows a log in screen that can be automatically shown after atime-out period has elapsed, to enhance security for the account user.This log in screen can be displayed to a user of a user interface module116 of a safety system 110, for example, and it can be especially usefulwhen the system 110 is accessed from a web browser over the internet,for example. Another view related to account security and controls thatmay provide similar functionality to that described with respect to FIG.23 is provided as one or more portions of FIGS. 3A, 3B, 3C, 3F, 5, 31and 32.

FIG. 24 shows an example user system 130 including a notification 2402(emphasized) received from the safety system 110 over a network 102.Parents can install a software application (e.g., a safety system plugin132 of FIG. 1, for example, the “WebSafety” mobile app, available fromWebSafety, Inc. of Newport Beach, Calif. as of October 2014 and itssuccessors) on their smart phones to provide features of the safetysystem 110. The safety system 110 can provide alerts or notifications tothe parent. In some embodiments, the safety system 110 can interrupt theoperating system of the user system 130 or any tasks running on theoperating systems of the user system 130 to provide the message 2402.

In some embodiments, the safety system 110 need not be installed on theuser system 130 of the parents. Instead, the safety system 110 can sendnotifications 2402 via SMS or data messaging to any e-mail or otheraccount. Parents may be monitoring more than one of their children.Thus, the notification 2402 can include the identity of the childconcerning the alert. In some embodiments, the notification 2402 canalso include a full quotation or an excerpt of the content at issue. Thecontent at issue can be a text message, a multimedia message, a URL,etc. For messages, the notification may also identify the sender or therecipient of the message. The safety system 110 can determine the threatlevel of the content to the child before interrupting the parent's usersystem. As shown in FIG. 24, the threat level is very high as thecontent of the message relates to a possible fight after school. Thethreat level can be determined based on keyword and/or phrase matchingor image recognition.

XVI. COMMUNITY FEATURES

Parenting is not easy. Parents are often at a loss to identify andresolve some of the issues that they encounter with their children. Thesafety system 110 includes technical solutions to assist parents on atleast two aspects of parenting—identification of a problem andpresenting solutions (or at least identifying resources for learning andfinding help leading to potential solutions). For example, parents mightfind through the safety system 110 that their children are being bulliedor harassed, or that they might be considering drinking or trying drugs.This can represent identification of a problem, and it can occur throughparental access to the texts, images, applications, or websites to whicha child is exposed.

FIGS. 25 to 30 illustrate community and support features that can beprovided by the safety system 110. This can represent resources forfinding help or understanding the problem, and it can save time byautomatically using the same underlying data or information that gaverise to the parental concern to locate relevant articles, content, orother online resources, and drawing a parent's attention to those items.For instance, relevant instructional or informational content can beprovided and access thereto (both passive and active) can be improvedthrough the systems described. A community for users to interact with asoftware provider and each other can be accessed, for example, through acommunity portal 2500 that may be an example of a user interface module115. Thus, a WebSafety blog (accessible through a blog access button2502) can include relevant content for users of a WebSafety softwaresystem. Experts in the community can keep users up to date, informingusers of the best ways to protect their children. A WebSafety forum(accessible through a forum access button 2504) can facilitate dialoguesbetween parents about the best ways to protect their children. AWebSafety customer support portal (accessible through a support accessbutton 2506) can also be provided as part of this community, and suchcustomer support can be technical and/or content-related. Support mayinclude automatically notifying parents through their computing devicesof new applications downloaded by their children and include adescription of the new application. The safety system 110 can obtaindescription of new applications from a data repository 150 of the safetysystem 110. The safety system 110 can update the data repository basedon information automatically retrieved from application stores, usercomments regarding the application, etc.

Technical features of the described system can allow better and fasteraccess to relevant background information on the topics raised by themonitoring and notification features of the described system. Forexample, automatic keyword searching or automatic alerts based on use ofany of the particular features described above can give rise to contentsuggestions—for example, links to relevant blog posts, support tickets,or forum discussions. Such automatic alerts can sort by relevance, date(putting most recent first), by user rating (putting those most used ormost highly approved or most-viewed first), etc. As discussed above, thesafety system 110 can determine certain keywords or identify contentfrom the images. For example, the safety system 110 can determine wordssuch as “drink” in messages: “Man, that was a close call at thecheckpoint; Told you shouldn't drink and drive.” Other examples areprovided in FIGS. 11, 12, 16, 37, 39, 42, 46, and 47. In someembodiments, the safety system 110 can also identify from images (forexample sent or received via messages, posted on Facebook, or SnapChat,etc.) that the child is holding a can of beer, for example. In anotherexample, the safety system 110 can automatically identify specificchildren using image recognition techniques or based on social networktagging.

The mobile safety monitor 110 can suggest content—for example, relevantarticles from social scientists, therapists, medical professionals orothers—based on the keyword and image detection. Content may not beunique to a user community for the systems and features described here,and can also be drawn from larger web searches or syndications services.Content can be marked as unique to the user community or as drawn fromother sources, and may include links to sources so users can assesscredibility. Content can be sorted by reaction or preference from a usercommunity, such that content giving rise to more comments, longerreading times, more forwards, etc. can be featured, de-emphasized, orremoved, depending on the type of feedback involved.

The safety system 110 can store in the data repository 150 written andaudio-visual materials such as articles, books, podcasts, or videos. Thedata repository 150 can also store links to professionals who may beable to assist parents in identifying solutions. The safety system 110can suggest content and/or provide access to professionals based onidentification of one or more issues discussed above. As an example,besides the notification of the “drink” message, the safety system 110can include links to articles dealing with alcohol and teenagers. Thesafety system 110 can also include link to one or more professionalsthat parents can directly interact with via text, audio, and/or visualcommunications. Accordingly, the safety system 110 can connect parentswith the resources they need to help their children.

The safety system 110 can also analyze a child's usage pattern of theiruser system to determine community content. For example, the safetysystem 110 can collect data on messaging use, application use, socialnetworking use, picture capturing usage by the child, etc. Based on thisgathered data, the safety system 110 can determine whether a particularbehavior with respect to using a computing device is deviating from thenorm. Accordingly, the safety system 110 can suggest to the parents, viaone of the user interfaces shown herein, community content that canassist parents. Further, the safety system 110 can be used to implementthe solutions identified in the content directly such as setting certainrestrictions or curfew on the use of one or more computing devices.Based in part on the drinking and driving text, for example, the safetysystem 110 can provide parents with an option to disable user system 130while the child is driving (that is when the user system 130 is movingat a speed over a threshold). The safety system 110 can alsoautomatically provide other restriction settings as described below withrespect to FIGS. 48 and 50 based on the monitoring described herein.

In an example, a safety system 110 can analyze a child's usage patternof their user system to determine content recommendations, using one ormore of the following technical protocols. For example, the safetysystem 110 can automatically implement or recommend curfew protocolsbased on child's usage patterns. For example, if the child is usingtheir phone while in school or driving, the safety system 110 canautomatically block the texting functionality of the phone. Further, thesafety system 110 can receive input from parents through a survey orquestionnaire to automatically recommend phone usage settings for theirchildren.

FIG. 26 illustrates user interfaces 2600A and 2600B that enable users ofthe systems described herein to ask technical questions about thesoftware including some or all modules of the safety system 110. Theseinterfaces may be used as a WebSafety customer support portal (that maybe accessible through a support access button 2506), and such customersupport can be technical and/or content-related.

FIGS. 27-29 illustrate example blog user interfaces. An interface 2700generated by the safety system 110 can provide some of the communityfeatures discussed above. This interface 2700 may be used as a WebSafetyblog (accessible through a blog access button 2502). Experts in thecommunity can keep users up to date, informing users of the best ways toprotect their children. The safety system 110 can customize the bloguser interface 2700 based on issues determined automatically throughmonitoring of their children. As discussed above, the safety system 110can select content from data repository 150 or external resources forpresentation to the parents based on monitoring of children. The content2704 may also be organized according to ratings or reviews of theparticle article or media content. The blogs user interface 2700 canalso include a blog roll 2706 listing some professionals who may haverelevant specialty in accordance with the parent's need as automaticallydetermined by the safety system 110. The blogs user interface 2700 canalso include articles or other media items 2702 that may be rated highlyby the community. The community can include other parents using thesystems described herein. In some embodiments, the community can alsoinclude professionals such as psychologists, doctors, or life coaches.FIG. 28 shows a continuation of the user interface 2700 includingadditional articles. A user can select one of the links corresponding toan article or a blog that can direct them to user interface 2900 (asshown in FIG. 29) with a more detailed view of the selected article.

FIG. 30 illustrates an example user interface 3000 showing a moredetailed overview of a professional listed in the blog roll 2706 of FIG.27. The user interface 3000 shows writings and other resources relatedto the particular professional selected by the user from the blog roll2706. As discussed above, the safety system 110 can identifyprofessionals based on monitoring children's user systems 130.

XVII. EXAMPLE REGISTRATION OR ACTIVATION PROCESSES AND USER INTERFACES

Further to the description provided herein with respect to FIG. 9, forexample, FIGS. 31 and 32 illustrate example embodiments of a process forenabling systems described herein on one or more user systems. Users caninstall a software application including some or all the modules of thesafety system 110 on their user systems 130. The safety system 110 canrequire email or other forms of validation to activate the software. Thesafety system 110 can provide parents with options to select whether thecomputing device with the software installed is to be used by a child orparent. When the computing device is selected as parent, the safetysystem 110 can send notifications and/or alerts regarding their childrento that particular computing device. For example, safety system 110 caninterrupt the operations on the user system 130 of the parent to displayalerts. When a particular computing device is enabled in the parentmode, that computing device can be used to control operations of othercomputing devices such as those belonging to a parent's children. Forexample, parents can use the safety system 110 on their user system 130to block some or all functionalities (for example texting, Facebook,etc.) in the children's user system 130.

In FIG. 32, the example process shows registration of a softwareapplication including some or all of the modules of the safety system110 on a user system 130 for a child. After installation, parents canselect that their child will be using the user system 130. Once the usersystem is selected to operate in child mode, the safety system 110 canmonitor that user system and control its operations as described herein.Setting up a child device can include filling out a profile (e.g., withname, date of birth, and e-mail) for that child. An example profileinterface page for a child is provided as FIG. 52.

In an example, a safety system 110 can provide a single applicationsoftware download that can function in either child mode or parent mode,depending on a selection in a process as indicated in FIGS. 3C, 31 and32, using one or more of the following technical protocols.

XVIII. EXAMPLE LOCATION USER INTERFACE

FIG. 33 illustrates an embodiment of a maps user interface 3300generated by the safety system 110 to show location information 3304 ofa child's user system (e.g., user system 130 of FIG. 1) on a map 3302.Other views related to map user interfaces that may provide similarfunctionality to that described with respect to FIG. 33 are provided asat least a portion of FIGS. 10A, 10B, 18, 33, 37, 38, 41, and 49. Themap 3302 can also include additional markers (not shown) for location ofschool, home, one or more friends' houses, etc. A calendar control 3312can be integrated into or accessible from the interface 3300. Thiscalendar control 3312 can be used to select the day for which locationdata to display. More granularity can be provided and movements can beplotted by minute, hour, and/or day and graphically superimposed on amap view. In some embodiments, location user interfaces may be generatedas described herein with respect to Location Agent.

In some embodiments, the safety system 110 can track location datareceived from the user system of the child over time and identifypatterns. For example, the safety system 110 can automatically send analert when the location of the child's user system has deviated from thenorm (for example, more than 100 yards, 500 yards, 1 mile, 5 miles, 25miles, etc. away from the school during the time when the child shouldbe in school, more than a threshold distance (e.g., 500 yards, 5 miles,20 miles, etc.) away from home any time of the day). The safety system110 can also determine if the child has visited a new location or isvisiting a particular location with high frequency. The safety system110 can store locations and location history in data repository 140.Accordingly, parents can use the user interface 3300 to determine wheretheir child's device was at a particular day and time by using the timebar 3306.

The length of time spent in a geographical location can also be tracked.If a child stays at a friend's house much longer than expected, an alertcan be generated. Thus, the calendar and mapping features describedherein can be combined to create a hybrid between the geofence featuresand the curfew or other scheduling features. Thus, a child's smart phonecan include software that automatically notifies a parent through aparent portal when a child deviates slightly or drastically from aplanned schedule. Dangerous or unwanted neighborhoods can be identifiedgeographically and parents alerted when a child ventures within a givendistance of such locations. The system can track or otherwise receivedata from other interactive applications that provide updates relatingto neighborhoods that may become more or less dangerous over time, andincorporate this data into automatic or suggested alert functions.

Location information can also be integrated with other functionality ofthe system. For example, certain applications may be allowed in somelocations, and not in others. Thus, a full curfew-based lock-down of thephone may not occur while Billy is attending his piano lesson at (MissJones' house at the corner of first and elm, for example), but certainrestrictions may apply, disabling all installed gaming applications butnot the phone, camera, and recording functions, for example. Thus, thesystem can be used to help improve the chances that a child will notonly be in the right place at the right time, but also will not beengaged in unwanted activities for that place and time. Although thecalendar feature illustrated in FIG. 33 only shows days, someembodiments can include a calendar with a more granular break-down ofhours and minutes, for example. Thus, an interface similar to the onespresented herein with respect to curfew controls (see, e.g., FIGS. 19,50A and 50B) can also be used in conjunction with geographic or otherlocation-related controls.

XIX. EXAMPLE NOTIFICATION ADMINISTRATION USER INTERFACE

FIG. 34 illustrates an embodiment of a notification administration userinterface 3400 generated by the safety system 110. This interface caninclude functionality similar to that described herein with respect toFIGS. 21 and 53, for example. Parents can use the administration userinterface 3400 to select alerts and notification settings for activityrelating to their children. For example, parents can input acorrespondence address 3402 (for example email), which can be used bythe safety system 110 to send alerts and/or notifications. In addition,parents can select notifications to be pushed directly on to the parentuser systems 130 that were enabled with the safety system 110 asdiscussed above. Notifications may be pushed or pulled via text messagesor through an application software installed on parent's user systems.Accordingly, the safety system 110 can interrupt a parent's user systemwhen an alert or notification is generated. Furthermore, parents canselect which alerts that they would like to receive. For instance, thesafety system 110 can generate alerts based at least on the parent'sselection of one or more of the following: text messages 3408, internetusage 3410, curfew 3412, GPS 3414, data connection 3416, and user systemapplications 3418, etc. The safety system 110 can also generate alertsbased on detected threat level as discussed above.

FIG. 34 also shows an add child user control 3430 that can be selectedto add an additional child to the tracking and safety system, and an addparent user control 3440. As with other controls illustrated herein,these controls can have hyperlink functionality that immediatelyswitches a user's view to a dialogue that prompts a user to input theinformation needed and to perform any other steps (such as installingsoftware on a child's mobile device) relevant to the indicated function.

XX. COMPUTING DEVICE STATUS USER INTERFACES

FIG. 35A illustrates an example user interface 3510 for activating thesafety system on the computing device. For example, users can activatesoftware including components of the safety system 110 using the activelink 3516. In some embodiments, the safety system 110 can include one ormore authentication mechanisms for enabling and disabling some or all ofthe features of the safety system 110 on a user system. Parents can usepassword authentication 3512 or fingerprint or any other biometricauthentication (not shown) to activate the software on the child's usersystem 130. Parents can also enable or disable, remotely over a network,some or all of the features of the safety system 110 on their child'suser system. Accordingly, in some embodiments, the safety system 110 canrequire authentication from parents on their user system 130 to ensuresafety and privacy protection of children. In the event that a parent'suser system 130 is lost or stolen, the authentication mechanism providedby the safety system 110 can protect privacy and safety of children.Parents may also be able to remotely disable their own user system 130which was lost or stolen using the safety system 110. In someembodiments, device status user interfaces may be generated as describedherein with respect to Device Status Agent.

FIG. 35B illustrates an example user interface 3520 generated by thesafety system 110 indicating status of the safety system 110 on aparticular user system 130. The status can indicate that the device iscurrently providing notifications and/or monitored. To exit or disablesafety system 110 on the user system 130, users can select active link3518 which may prompt authentication mechanism 3514.

FIG. 36 illustrates an example user interface 3630 generated by thesafety system 110 indicating that the user system 130 is in curfew mode.As discussed with respect to FIGS. 4, 19, 50A, and 50B, for example, thesafety system 110 can disable all or some of the functionalities of acomputer device 130 based on customizable curfew settings includingcurfew time period selected by parents using the safety system 110. Thecurfew settings can be stored in the data repository 140. The safetysystem 110 can access curfew settings over the network 102. Accordingly,the safety system 110 can automatically enable and disable curfew modebased on the stored curfew settings. In some embodiments, the safetysystem 110 enables curfew mode in real time based on a command receivedfrom a parent's user system 130. Thus, parents may use the safety system110 to enable curfew mode instead of taking the phone away from thechildren.

In some embodiments, the safety system 110 inhibits all of thefunctionalities of the user system 130 when curfew mode is activated. Insome embodiments, the safety system 110 can permit voice calls to apreselected group of individuals including emergency numbers using link3632 in curfew mode. The safety system 110 can prevent bypassing thecurfew screen 3630 by using authentication processes described above. Insome embodiments, the safety system 110 can block features of the usersystem by accessing the boot module of the operating system running onthe user system 130. The safety system 110 may also generatenotifications when a user (for example child) attempts to bypass thecurfew screen 3630. The safety system 110 can transmit the notificationsto parent's user system 130.

In some embodiments, the safety system 110 can automatically enablecurfew mode when the child is driving. The safety system 110 candetermine the speed at which the user system 130 is moving and enablecurfew mode when the speed exceeds a threshold. The threshold can be 25mph.

XXI. EXAMPLE DASHBOARD USER INTERFACE

FIG. 37 illustrates an embodiment of a dashboard user interface 3700generated by the safety system 110. This dashboard interface 3700 caninclude functionality similar to, in addition to, or as alternative toembodiments described herein with respect to FIGS. 10A, and 11, 39, and41, for example. In some embodiments, the safety system 110 canaggregate monitoring data from multiple sources in one place—a dashboarduser interface such as the interface 3700. Thus, parents can efficientlyreview data regarding their children's smartphone usage, includingmessages third parties send to their children, by accessing and viewingthe dashboard user interface 3700. The safety system 110 can visuallysort data in the dashboard user interface 3700 based on one or morecriteria. For example, the safety system 110 can display notificationsaccording to a timeline 3701 as illustrated in FIG. 37. The safetysystem 110 can also highlight relevant portions (for example words like“drunk” or “pregnant”) of the notifications. In some embodiments, thesafety system 110 can summarize each day's notifications in an alertsummary bar 3730. The alert summary bar 3730 may include an indicationof how many recent notifications have been generated related to one ormore of the following categories, with a number displayed in associationwith icons representing the source and area of the alerts as follows:application software 3732, SMS 3734, internet (www) 3736, map 3738, andcurfew 3740. Many of the views and interfaces illustrated herewith shownumbers representing alerts; it can be helpful to set off the numberagainst a visually contrasting background to make it more likely to benoticed and visible to a user.

The timeline 3701 of FIG. 37 is particularly data rich, because itintegrates information from various aspects of a safety system 110. Ituses icons at the left to identify the source of the various alerts,while still sorting them chronologically. The icons include a clock,designating a curfew action, stacked stylized conversation bubbles todesignate an alert sourced to a text message, a stylized grid indicatinga new potentially harmful software application was installed, and astylized globe showing a website was visited. The icons can beselectable and immediately transform the view visible to a user to amore detailed summary of the relevant aspect of the safety system 110.The timeline can continuously or periodically refresh, allowing thenewest alerts and information to remain in the view most immediatelyavailable to the user, but allowing a user to scroll down for a morecomplete history, with downward scrolling taking the user farther andfarther back through a recorded history of previous alerts and otherinformation. A similar chronological organization can be presented in animage section such as the photos summary 3760. In some embodiments, oneor more of the portions 3701, 3742, 3750, and 3760 can be virtuallyuntacked from their currently-illustrated positions and their positionsand prominence in the view can be interchangeable. In some embodiments,a similar function can be accomplished by dynamically visuallyemphasizing one of the four at the left when it is selected, whilesimultaneously de-emphasizing the other three by displaying them to theright.

The safety system 110 can also generate a location status 3742 of thechild and include it in the dashboard interface 3700. For instance, thedashboard interface 3700 can include a map with a location status 3742of the child's user system. In some embodiment, parents may use thesafety system 110 to activate the GPS module in the child's user systemremotely to get a better location of the child's user system. The safetysystem 110 can monitor a status of the child's user system 130,including status of communications module of the device 130, asindicated in the device status portion 3750 of the dashboard interface3700. The communications module of the device can include dataconnection, GPS, or NFC. The safety system 110 can poll the device 130for status of its modules. In some embodiments, a module of the safetysystem 110 resident on the child's user system 130 (e.g., a plugin 132)can monitor the status of the user system 130 by polling the operatingsystem of the user system 130 or by directly accessing particularhardware or software modules of the user system 130. The safety system110 can include the status 3750 of the child's user system in thedashboard user interface 3700.

The dashboard user interface 3700 generated by the safety system 110 canalso include a photos summary 3760 related to a child. As discussedabove, the safety system can mine a child's user system for photostaken, sent or received via the child's user system 130. In someembodiments, the safety system 110 can intercept the photos and/orvideos taken from the memory of the user system 130 before they aredeleted by applications like Snapchat or by users of the user system.The safety system 110 can also mine through social networking datarepositories to retrieve pictures and/or videos related to the child.The safety system 110 can use image recognition or use a child'spassword to obtain the photos and videos from the child's account. Insome embodiments, the corresponding comments relating to the images arealso retrieved by the safety system 110. Selecting the photos summary3760 can change a view focusing on the photos that may be similar toFIG. 40, for example. Comments and other information regarding thephotos may be available when the photo is selected in that more focusedview. The safety system 110 can group photos retrieved from varioussources described above in the photo summary section 3760. In someembodiments, the photos may grouped by relevance to child's safety. Forexample, the safety system 110 may selective display photos that mayseem lewd, or is associated with a troublesome comment, or includespictures of alcohol, etc. The photos may also be arranged inchronological order, arranged by source, etc.

The dashboard user interface 3700 generated by the safety system 110 caninclude a contacts summary bar 3720 that can illustrate a group ofpeople who communicate with a user of a user system 130. For instance,the safety system 110 can monitor communications from the user system130 and via social networking platforms as discussed herein. Based onthe monitoring, the safety system 110 can determine a group of peoplethat a child communicates with most frequently using various modes ofcommunications. The safety system 110 can display this group of peoplewith high communication frequency in the contacts summary bar 3720 asillustrated in FIG. 37. The safety system 110 can automatically removeparents or family members from this group of people, in someembodiments. The safety system 110 can retrieve pictures of people inthat group for display in the contact summary bar 3720. The pictures maybe retrieved from a person's social networking or phone profile (forexample, using a designated contact photo). The safety system 110 mayalso calculate statistics (for example percentage communication) for thegroup of people as discussed more in detail with respect to FIG. 41.

Parents can also navigate between monitoring multiple children. Forexample, the safety system 110 can store monitored data for each of thechildren using respective computer devices in data repository 140. Basedon the stored data, the safety system 110 can generate the dashboarduser interface 3700. In some embodiments, the safety system 110 candistinguish notifications based on children. For example, parents canselect a link 3702 corresponding to a first child or links 3706 and 3710for second and third children, respectively, to access monitored datafor each child. In some embodiments, the safety system 110 can indicatenew notifications 3708 by superimposing numbers on icons representingparticular children as illustrated in FIG. 37. The notification icon3708 can indicate a number of new notifications since the dashboard waspreviously viewed, new notifications, in the last day, new notificationsin a preceding amount of time designated by (and adjustable by) theuser, etc.

Parents can share information from a dashboard view (or any of thedisclosed views) with each other. For example, a screen shot from theparent portal can be automatically e-mailed to a spouse or saved forlater reference or proof. When time, place, and activity trackingfunctions are combined as discussed herein, each child can have a singlestatus indicator showing how the child's current location and activities(for example, phone usage) may or may not currently comply with acomprehensive schedule created by the parent or child, for example.Periods of non-compliance can be tracked and recorded. Children cancompete with each other to achieve higher levels of schedule complianceand be rewarded with later curfews or other differences in allowed phoneusage. The disclosed systems can automatically arrange and administersuch beneficial competition because it tracks usage, timing, andlocation, as well as controls smart-phone lock-out and other curfewoptions. Thus, obedience and other desired behavior can be incentivizedautomatically using the system.

The safety system 110 can also include a sidebar 3770 to access otheruser interfaces generated by the safety system 110 as discussed withrespect to FIG. 10A, for example. In some embodiments, the safety system110 can generate a sidebar 3770 including an application summary link3772, SMS summary link 3774; internet summary link 3776; locationsummary link 3778; curfew summary link 3780; picture summary link 3782;and community features summary link 3784. Parents can select one of thelinks in the sidebar 3770 to access a user interface corresponding tothe selected link.

FIG. 37 is one of various figures illustrating how the disclosedsystems, apparatus, and methods can automatically extract and assembledata from complex, moving electronic devices and assemble that data inorganized and graphically efficient views. For example, the dashboardview of FIG. 37 can aggregate highly complex and data-rich informationfor various children (here, Billy, Jenny, and Johnny), and rapidlyswitch between views for each of the children. A timeline, a map, listof interlocutors, a device status, and a mosaic of images, all viewableat once on the same screen, and almost all of which actually representlive hyperlinks that lead to related webpages, content, and context.Thus, this graphical display allows efficient review and further accessand information by a user of a parent portal. The dashboard assemblesdata in a highly organized and efficient manner, but also acts as adashboard organizing active control functionality.

FIG. 38 illustrates an embodiment of a process for generating orrefreshing a dashboard user interface 3700. As discussed herein, thesafety system 110 can access and extract data from or about more thanone of the user system's software application and/or hardware modules.The software applications can include a texting application, a socialmedia application, an image application that facilitates transmission orreception of images, and a web browser application. Hardware modules caninclude location module or communications module or battery. In someembodiments, the extracted data can be sent to an analysis server. Theanalysis server can identify potentially harmful language, images, andwebsites by comparing the extracted data to existing databases ofharmful words, harmful images or image types, harmful websites, andharmful applications. The generated results from the analysis can besent to a parent portal for display such as that of FIG. 37.

FIG. 39 illustrates another embodiment of a dashboard user interface3900 generated by the safety system 110. In the illustrated embodiment,the notifications are limited to Facebook notifications for a particularchild (“Billy”). The safety system 110 can enable parents to reviewnotifications corresponding to a particular application software orsocial networking website. For example, parents can select a particularapplication from a list of applications as described more in detail withrespect to FIGS. 14, and 43-45. Using Facebook as an example, the safetysystem 110 can generate the dashboard user interface 3900 includingFacebook related notifications. The safety system 110 can use aggregatedFacebook data for a particular child stored in data repository 140. Theicons at the left of the timeline view 3910 (e.g., Facebook icon 3912)can indicate the source of the information displayed. As with othertimeline views discussed herein, text can be provided indicating howlong it has been since the noted event occurred. A comment can be shownin a conversation bubble, and a photo or other identifier for a personmaking the comment can also be shown. As discussed herein, the safetysystem 110 can retrieve information from Facebook through anauthentication handshake with Facebook servers and/or API.

FIG. 40 illustrates another embodiment of a photo/video summary userinterface 4000 that can be generated by a safety system 110. In theillustrated embodiment, only pictures corresponding to Facebook areillustrated (as indicated here by the Facebook icon associated with eachphoto), but the safety system 110 can also include photos taken ordownloaded on a child's computing devices or received via messaging, orfrom other social networking sources. Accordingly, parents can quicklybrowse pictures related to their child in one place. As discussed above,the photos can be organized according to threat relevance, or they canbe organized chronologically, sortable by source, etc.

FIG. 41 illustrates an example dashboard user interface 3700 generatedby the safety system 110 that includes a contacts summary bar 4102 thatcan display statistics directly on the user interface. The illustratedview of the contacts summary bar 4102 can be selected or otherwisecontrolled by a user such that the view toggles between that shown hereand the more compact view illustrated for the contacts summary bar 3720in FIG. 37. In the view of FIG. 41, the bar is expanded to show bargraphs indicating the relative frequency of communication with a set ofpeople. This expansion and reduction—toggling between the versionsshowing in FIGS. 37 and 41—can be accomplished with a specific button orcontrol. For example, the icon 3716 (which includes a stylized bar graphicon) can be selected to change this view. An “X” in the top rightcorner of the contacts summary bar 4102 can be used to close theexpanded view, for example. In some embodiments (and as illustrated inthis example), the bars in a bar chart can be capped with a photographicrepresentation of these interlocutors, or with placeholders for suchphotographs. As discussed above with respect to FIG. 37, the contactssummary bar 4102 can include a group of people in communication with auser of the computing device 130. The safety system 110 canautomatically generate graphs and sort this group of people based on theamount of interaction (calculated by number of communications, numberand length of communications, or using other methods), includingmessaging via SMS, Snapchat, Facebook, WhatsApp, phone calls, etc. Insome embodiments, the safety system 110 can assign weights to certaintypes of communication to determine a representative amount ofinteraction for comparison. For example, a child may send 100 messagesper day to a first friend, but may spend half an hour on the phone perday with a second friend. The safety system 110 can appropriately weightthe messages with the phone time to compare the time spent by the childwith the first friend versus the second friend. Accordingly, parents caneasily view a snapshot of who their children mostly interact with usingtheir smart phone. In some embodiments, the user interface 3700 allows auser to select for comparison a subset of communications (for exampletext messages). Thus, rather than an aggregation of all communications,a visual comparison can be provided indicating with whom a child has themost frequent and/or longest lasting communications by a particularchannel—e.g., SMS texts, e-mails, phone calls, etc. The safety system110 can also allow a parent to select a time frame from which to drawthe data for the statistical bar graph comparison (e.g., using the“today” button 4112, the “this week” button 4114, or the “all time”button 4116) as illustrated in FIG. 41. The graphs generated by thesafety system 110 can be illustrated in a wide variety of forms. Forexample, in the illustrated embodiment, the safety system 110 generatesa bar graph with each bar 4104 including a face profile of the relevantperson (e.g., drawn from one of that person's social networking sites orprofiles) and a communication metric (for example 40%, meaning thatapproximately 40% of Bill's total communications in the relevant timeperiod have been with that person). In some embodiments, the size of thefaces can be enlarged proportionally to the number of communications(e.g., as an alternative to including taller bars for the mostfrequently communicating parties). The example contacts summary bars3720 and 4102 can both include a visual indication of which child'sconversations are being summarized. In FIG. 41, a conversation feature4190 is illustrated as pointing to the photograph of Billy. This causesthe contact summary bar 4102 to resemble a stylized conversation bubble,indicating that Billy is conversing with the people shown. Billy's photois also set off by a thicker border, providing an example of how avisual display can provide emphasis and draw attention to indicate whichof the children's activities are being summarized in the current view.

FIG. 41 (among others) illustrates how the disclosed systems, apparatus,and methods can automatically extract and assemble data from complex,moving electronic devices and assemble that data in organized andgraphically efficient views.

FIG. 42 includes a notification summary user interface 4200 generated bythe safety system 110. The notification summary user interface 4200 caninclude a number of notifications sorted according to child and time,with headings for each day as shown.

FIGS. 43-45 illustrate embodiments of application summary userinterfaces generated by the safety system 110. For example, FIG. 43illustrates an application usage interface 4300 including a graph 4310showing usage statistics of application software on a child's usersystem 130. The safety system 110 can retrieve statistics stored in adata repository (e.g., user parameters 140 of FIG. 1) based onmonitoring as discussed above. In some embodiments, the graph 4310 caninclude a pie chart as illustrated in FIG. 43. This pie chart or analternative display showing application usage can also be included on adashboard view (in place of or in addition to the portions 3742, 3750,and/or 3760 of FIG. 37, for example). The graph 4310 can also include(or be replaced by) a bar chart or other graphs suitable for displayingpercentage usage of different software applications. The safety system110 can monitor application usage based on one or metrics. For instance,the safety system 110 can monitor usage based on tracking the amount oftime a particular application is running, open, and/or visible to a useron the display of the user system. Other metrics can include amount ofdata used or number of messages sent. In some embodiments, applicationsrunning in the background or running while a smartphone is in sleep modecan be not included as “used” during that time period; similarly, usecan be defined to require that a child has been either actively viewingor interacting with them to count as being “used.” The safety system 110can also provide a time period selector 4312 for parents to reviewapplication usage over a particular time period. The safety system 110can determine an application most frequently used by the child (“TopApp” 4328) on the user system 130 in the relevant time period andinclude it in the generated application usage interface 4300 as shown.The usage interface 4300 can also include an application usage listing4320 with a last used time 4322 indicating when an application was lastaccessed. The safety system 110 can retrieve this data stored as part ofmonitoring the user system 130 in a data repository (e.g., userparameters 140 of FIG. 1). The safety system 110 can also retrieve astored description 4326 of an application from a data repository (e.g.,system parameters 150 of FIG. 1). The stored description 4326 may beautomatically obtained based on description from other parents orapplication store.

FIG. 44 illustrates a current applications interface 4400 generated bythe safety system 110. As discussed above, the safety system 110 canidentify applications of concern installed on a child's user system 130.In some embodiments, the safety system 110 polls the operating system ofthe user system 130 to identify installed applications. The safetysystem 110 can store the applications in the data repository 140. Whennew applications are installed and existing applications are deleted,the safety system 110 can update the list of applications stored in adata repository (e.g., user parameters 140 of FIG. 1). Further, thesafety system 110 can also maintain a list of application software, itsratings, and description in a data repository (e.g., system parameters150 of FIG. 1). The list can be updated based on community feedback.Using the stored data, the safety system 110 can generate the currentapplications interface 4400. In some embodiments, the currentapplications interface 4400 includes a list of “applications of concern”4412. Further, the safety system 110 can also provide a description 4420for each of the applications of concern in some embodiments, which maybe generally hidden until a particular application or related icon isselected, for example. As illustrated, the safety system 110 can alsosort applications between those of concern and others which are alsoinstalled on the user system 130, but which may not be known for posingpotential danger to children.

FIG. 45 illustrates an application installations interface 4500generated by the safety system 110. As discussed above, the safetysystem 110 can track installation and removal of application software onthe child's user system 130. Further, the safety system 110 may storethe time an application was installed or removed in a data repository(e.g., user parameters 140 of FIG. 1). Based on this stored data, thesafety system 110 can generate the application installations interface4500 including a listing 4512 of applications installed or removed andthe corresponding time that the child took that action.

FIG. 46 illustrates an embodiment of an SMS activity interface 4600generated by safety system 110. This example may provide functionalitysimilar to that discussed with respect to FIG. 16. As discussed withrespect to FIGS. 15 and 16, for example, the safety system 110 canmonitor and store messaging communications originating from or receivedat each of the child's user systems 130. In some embodiments, theanalysis module of the safety system 110 can identify messages ofconcern as discussed above. The safety system 110 can aggregate messagesof concern based on the child and the contact person. In the illustratedSMS activity interface 4600, messages from Billy to Jacob are shown asper a user's selection. While all messages related to a contact may beincluded in the SMS activity interface 4600, the safety system 110 cansort through the messages to include only messages of concern. Further,words of concerns may be highlighted by the safety system 110 in themessages. In some embodiments, the safety system can include a blockedindicator 4420 to show whether a particular contact related to themessage is blocked. Parents may select a contact for blocking using theindicator 4420. The safety system 110 can intercept messages fromblocked contacts and may not show the blocked messages to the childuntil reviewed by parents. In some instances, the safety system 110 canautomatically block messages based on content and display it in the SMSactivity interface 4600 for parental review. In some embodiments, thesafety system 110 can automatically block the contact such that messagescannot be received or sent to the contact based on detecting content ofconcern in messages. The safety system 110 can also detect if the numberof the blocked contact or a method of communication with the blockedcontact has changed. Accordingly, the safety system 110 can preventblocked contacts or users from circumventing the system. The safetysystem 110 can track if a message belongs to the same contact previouslyblocked based on continuity of conversation, the contact's phone ID (forexample mail account, MAC address, etc.).

In some embodiments, the safety system 110 may modify the contactsummary bar 4410 included in the SMS activity interface 4600. Forexample, the safety system 110 may organize and sort contacts in the bar4410 based solely on SMS instead of other modes of communicationsdiscussed above with respect to FIG. 37. The safety system 110 can alsoinclude search toolbar 4430 to enable parents to search through messagescommunicated via the child's user system 130.

FIG. 47A illustrates an SMS filters interface 4700 generated by safetysystem 110. This example may provide functionality similar to thatdiscussed with respect to FIG. 15. Parents can use the SMS filtersinterface 4700 to manage messaging communications (for example SMS) fromtheir child's user system 130. As discussed above, the safety system 110can auto block certain messages and contacts. In some embodiments,parents can modify auto block settings 4702 and 4704 via the SMS filtersinterface 4700. For example, parents can select a number of words ofconcern (or filtered words) 4704 before a contact is automaticallyblocked. The safety system 110 can include a list of blocked senders4706 in the SMS filters interface 4700. FIG. 47B illustrates anotherembodiment of an SMS filters interface 4720 generated by safety system110. The SMS filters interface 4720 can include a search filter listcontrol 4722 to review whether a particular word is being monitored orfiltered. As discussed, users can add words to the filtered words liststored in data store 140. FIG. 47C shows that, in one embodiment, when auser begins typing a particular word, the safety system 110 can retrievewords from the filter list similar to the typed word. Accordingly, theuser can identify the words in the filter list based on their input. Ifthe word is not in the filtered list, the user can add their inputtedword into the filtered list. The safety system 110 can store the newword and include it in monitoring past and future communications.

FIG. 47C illustrates an embodiment of an SMS analytics interface 4730generated by the safety system 110. The SMS analytics interface 4730 cangenerate overall summary based on SMS communications sent and/orreceived by one or more user systems 130 belonging to respectivechildren. The SMS analytics interface 4730 can enable parents tovisually identify SMS offenders and SMS related issues with respect totheir children. For example, the safety system 110 can identify wordusage frequency from the filtered list. In the illustrated embodiment,the top 20 words that are used in SMS communications from the filteredlist are shown in a listing 4738. In some embodiments, the listing 4738is sorted by usage frequency of words in the filter list. The listing4738 may identify a user associated with the word. For example, thelisting 4738 may identify the user who has received and/or sent theoffensive word with the highest frequency compared to other users. Thelisting 4738 may also include an icon identifying the source of theword. For example, the icon can include a symbol or color correspondingto one of the applications, such as Facebook, SMS, etc. In someembodiments, when a particular word is selected from the list 4738, thesafety system 110 can show additional details 4740 related to theselected word. A word can be selected based on clicking on it orhovering over it. Additional details 4740 can include a listing of usersassociated the selected word and the corresponding frequency of usage.In addition to the listing 4738 and details 4740, the safety system 110can generate a graphical summary 4732 to visually organize SMS summary.In one embodiment, the graphical summary 4732 is a pie chartillustrating a distribution of offensive word usage frequency. In theillustrated example, “sucks” is the most frequently used offensive wordin the SMS communications, which may include sent and/or received SMSmessages. The safety system 110 can generate additional details 4734when a particular word or a graphic element corresponding to the word isselected. As discussed above, selection may be a function of a click ora touch input or hovering over the area of interest. As shown, theadditional details 4734 can visually show children associated with theselected offensive word. In the illustrated embodiment, the safetysystem 110 shows a pictorial representation of Billy, Jenny, and Johnnyfor being associated with the offensive word “frick.” The safety system110 can show a graphic 4736 when Johnny is selected. The graphic canindicate that Johnny used the offensive word “frick” 5 times. The safetysystem 110 can enable customized analysis of SMS data. For example, insome embodiments, parents may be able to generate graphs 4732 based onselecting one or more of the following factors: sent messages, receivedmessages, one or more children, time period, etc.

In some embodiments, the safety system 110 can enable parents to definetheir own custom rules 4708 for filtering messages. For instance,parents can select certain words (for example “drunk”) or terms andconnectors (“drunk” near “driving”). The safety system 110 can use thesecustom rules to filter messages. The safety system 110 can also trackword usages and include a listing of most used words in a list 4710 asillustrated. The safety system 110 can employ image recognition oroptical character recognition to prevent contacts from using picture inmessages to avoid bypassing filters.

FIG. 48 illustrates a web access interface 4800 generated by safetysystem 110. This example may provide functionality similar to thatdiscussed with respect to FIG. 17. The web access interface 4800 canprovide parents options to control which websites can be accessed onchild's user systems 130. For example, parents can select a flaggingmode 4810. Based on the selected flagging mode, the safety system 110can block a list of problem websites and/or flag these list of problemwebsites. The safety system 110 can allow parents to input the list ofproblem websites as illustrated at 4820. In some embodiments, the safetysystem 110 can automatically suggest problem websites based oncollaborative feedback from users.

FIG. 49A illustrates an embodiment of a location user interface 4900generated by the safety system 110. The example of FIG. 49 may providefunctionality similar to that discussed with respect to FIGS. 18 and 33.The location user interface 4900 can provide parents with a visualnotification of where their children's user systems 130 are currentlylocated and where they have been in the past. In some embodiments, thesafety system 110 can generate a map 4910 to display the locationinformation 4912 of the respective user systems. In some instances, thesafety system 110 can show all the user systems belonging to each of thechildren on one map 4910. The safety system 110 can include landmarks onthe map 4910. Landmarks can include school, home, a circle with a radiusof preset distance from home or school. In some embodiments, the safetysystem 110 can also display most frequently visited locations on the map4910. The safety system 110 may also include a search bar 4914 that canallow a parent to lookup location history of the child's user system. Ageographic movement pattern (comprising a tracing of a route, forexample) can be graphically disassociated from the underlying map andcompared to other movement patterns—e.g., by superposition and/orjuxtaposition, holding map size generally constant between data sets,etc.—to assist a user with review and comparison.

FIG. 49B illustrates location history data 4920 generated by the safetysystem 110. In some embodiments, the location history data 4920 can beincluded in the dashboard described above. The location history data4920 may also be shown in a separate window or separately from othernotifications. In the illustrated example, the location history 4920shows location updates of Billy's phone. The location history 4920 mayalso show other devices belonging to either Billy or other children. Thelocation history 4920 may be sorted according to a chronological order.In some embodiments, the location history 4920 may be sorted accordingto priority of alert which may depend on a determination by the safetysystem whether the location might be deviating from the norm. Eachlocation notification may identify a child, an event, and a place orgeofence associated with the event. For example, the illustrated exampleshows that “Billy left Home”, “Billy arrived at School”, “Billy hasentered restricted location ‘The Mall’, and “Billy has left the safeplace ‘Our Neighborhood.’” The locations identified in the notificationsmay include places or geofences. For example, places may include “home”,“school” and the “mall” while geofences may include “our neighborhood”.

FIG. 49C illustrates an embodiment of an interface 4930 for selectingand storing places and/or geofences using the safety system 110. Theplaces and geofences created can be unique to a user or applied amongmultiple users. A parent can select a place using control 4936A as shownmore in detail with respect to FIG. 49F. Further, a parent can create ageofence using control 4936B as shown more in detail with respect toFIG. 49G. In some embodiments, the safety system 110 can provide a mapin the interface 4930. As discussed above, the safety system 110 canvisually display a location 4934 of a user system 130 on the mapprovided in the interface 4930. In the illustrated example, Billy'sphone is located at 4934 on the map which may correspond to an addressor a known location or one of the stored places. Known locations caninclude malls, restaurants, schools, friend's houses, dentist, doctor'soffice, etc. The safety system 110 can store known locations based onuser input and/or third party data sources. The safety system 110 candisplay an address or known location 4932 along with the location 4934of Billy's device. Further, the safety system 110 can enable users tosave current location as one of the places for future recognition. Insome embodiments, the safety system 110 can also include a timelinesearch as described with respect to FIG. 49D.

The safety system 110 can enable parents to track location of childrenover time using a timeline search control 4942 shown in FIG. 49D. In theillustrated example, the last 7 days are selected for timeline search.The active link 4942 can enable parents to select any time period. Basedon the selection of a time period, the safety system 110 can retrievestored location data about a particular user system 130 from the datarepository 140 for the selected time period. In some embodiment, thesafety system 110 can generate visual indications 4938 on the map basedon the retrieved data. The visual indications 4938 may show a path oftransit of the user device 130 over the selected time period. In someembodiments, the visual indications 4938 can show only places ofinterest and discard transit information. The safety system 110 can alsohighlight certain locations 4946 and 4944 in the visual indication 4938,as shown in FIG. 49E. The safety system 110 can also indicate a periodof time that a user system 130 was at a particular location. The safetysystem 110 can automatically identify in the visual indications 4938,particular locations (4944 and 4946) where the user system wasstationary (with respect to the boundary of that location) for at leasta predetermined time period. In one embodiment, the predetermined timeperiod is 15 minutes. In some embodiments, the predetermined time periodcan be more than 15 minutes or less than 15 minutes. For example, thepredetermined time period can be 30 minutes or 1 hour. As discussedabove, the safety system 110 can store places like homes and school.Accordingly, the safety system 110 can illustrate on the map storedplaces. Further, the safety system 110 can also show on the map newlocations (for example, “Billy was at 251 W 3^(rd) St for 15 m”).Accordingly, parents can get a visual snapshot of their children'swhereabouts over a time period and identify places that their childrenare frequently visiting. For example, parents can identify trends suchas Billy was at school for a shorter duration than normal hours onWednesday (as shown in the figure). In another example, parents canreview a new location—251 W 3^(rd) St that Billy stopped over for 15minutes.

FIG. 49F illustrates an example for using the interface 4930 to identifyand store a new place. For example, parents can select a control 4952 toadd a new place. Parents can enter a name of the place, select whetherthe place is a safe place or a place for concern, or select whether toapply the place for a particular child or all the children. Further,parents can select notification settings for safety system 110 for whento generate alerts with respect to the new place. For example, in someembodiments, parents can select to generate notifications when thechild's user system 130 enters and/or leaves the newly added place. Thegeographical location of the place can be selected by entering anaddress in the control 4952 or selecting a location 4950 on the map. Thesafety system 110 can also suggest locations 4946 based on the user'sinput via text or map. Parents can also select a color 4954 or otheridentification symbol for the newly added place. The safety system 110can also include in the map predetermined locations such as stores orrestaurants or any other places of interest. Parents can select one ofthese predetermined locations as a stored place.

FIG. 49G illustrates an example for using the interface 4930 to add ormodify geofences. A geofence can indicate a bounded area on a map.Parents can select a particular shape 4958 based on their desiredpreferences for a particular geofence. For example, parents may create aneighborhood geofence as a safe place and select alerts for whenever auser device crosses a boundary of the geofence. In some embodiments,parents may draw any shape on the map to create a geofence. In theillustrated embodiment, parents can drag points on a shape 4958 tocreate the geofence. Further, the safety system 110 can enable parentsto drag points of the shape to automatically snap on to streets orintersections displayed on the map. In the illustrated embodiment, theshape 4958 can include eight points that can be dragged to create ageofence. Furthermore, the position of the shape 4958 corresponding to ageofence can also be moved on the map. Parents can assign a name, color,or symbol to identify the geofence. The name, color, or symbol may beused by the safety system 110 in the notifications. Parents can alsoselect when they would like to be notified for the created geofence. Forexample, the safety system 110 can provide options for parents to enablenotifications when the user system 130 enters and/or leaves thegeofence. The safety system 110 can also enable parents to apply thegeofence to some or all of their children as illustrated in FIG. 49G.Further, the geofence can be associated as a safe place or a place ofconcern. Based on the selection, the safety system 110 can modify itsnotifications with respect to the geofence.

FIG. 49H shows a list of geofences and places 4960 added by parentsusing the interface 4930. Further, parents can selectively turn on andoff notifications corresponding to the selected geofence or places asshown in the figure. The illustrated figure also shows a path of thechild's user system 130 for the particular day including stops and thelast location. The known stops can be displayed on the map as shown inFIG. 491. In some embodiments, parents can select whether to show aparticular place or geofence by selecting an active control 4962. Activecontrols can include links, hyperlinks, buttons, check box, etc.

FIG. 50A illustrates an embodiment of a curfew user interface 5000generated by the safety system 110. The example of FIG. 50A may providefunctionality similar to that discussed with respect to FIG. 19. Thecurfew user interface 5000 can enable parents to select curfew settingsfor their children's user systems 130. The curfew settings 5010 caninclude day and time when a particular set of curfew rules may beactivated by the safety system 110. In the example of FIG. 50A, thecurfew settings rules are preselected to completely disable the usersystem except for some phone services as discussed above. Accordingly,parents can select times of day to enable and disable curfew to preventchildren from using their user systems 130 during school, after bedtime,homework time, etc.

FIG. 50B illustrates another embodiment of a curfew user interface 5050generated by the safety system 110. As shown by the pictures of Billy,Jenny, and Johnny in this view, their parents have been using thedisclosed systems, resulting in improved attitudes and demeanors intheir profile photos. In the curfew user interface 5050, parents canselect virtual slider control knobs 5014, displayed above each daycolumn, to enable curfew settings on or off for that day of the week.Further, parents may be able to select time slots of restrictions byclicking anywhere on the calendar to create new boxes. Resizable boxes5020 are illustrated superimposed on a calendar view 5024. Parents canalso move and drag boxes, and/or the borders and edges of boxes, toadjust the timing and/or duration of the restricted use periods orcurfews. Parents may find it efficient to use the curfew user interface5050 in some instances on a touch screen computing device. Similarinterfaces can be used for other settings and interactions with a safetysystem 110. For example, resizable, moveable shapes, superimposed on amap, for example, can be used for setting geographic restrictions,geo-fencing, etc.

As discussed herein, the safety system 110 can apply curfew settingsautomatically based on locations, places, or geofences. For example,entry into a safe zone or getting out of curfew time may automaticallyreactivate some of the functionality of the user system 130.

FIG. 51 illustrates an interactive “devices” screen 5100 of an accountuser interface generated by a safety system 110. This screen can begenerated by or associated with the account management module 120 ofFIG. 1.

Account settings interactive screens, such as FIG. 51, can be accessedusing a control associated with the “Welcome, Rowland Day” dropdown menuindicator 5101, which can initiate a menu showing a “log out” control ora “my account” control. The “my account” control (not shown) can beselected and result in various settings pages, accessible by the tabs5103. As illustrated here, the “my account” bar 5132 can include apointer 5136 indicating that the current account is that of the exampleparent, Rowland Day (protecting children since Feb. 11, 2011). Anadditional parent or guardian can be added using the add parent button5142 and an additional child can be added using the add child button5147.

The tabs 5103 can include, for example, an “account info” tab, a“profile” tab, a “notifications” tab, and a “devices” tab. The devicesscreen 5100 can be accessed by selecting the device tab, and this screencan include an existing device box 5102 showing details of devicesalready added (and allowing for their removal), as well asadministrative tools to register additional controller user systems 130(e.g., user systems 130 used by parents) with the safety system 110. Thesafety system 110 can add a registered controller user system 130 as oneof the devices to send notifications to regarding child user systems 130using the add device control 5104. For example, both parents can receiveupdates from children's user system 130 once their devices areregistered with the safety system. Subscription plan information can beincluded at 5112, a devices installed and remaining dialogue 5120 can beprovided, and an “upgrade” button 5124 can allow a user to increase thenumber of registered devices.

When Billy's identifier 5214 is selected from an account managementscreen (e.g., the screen shown in FIG. 51), rather than navigate to adashboard view for Billy (e.g., the view shown in FIG. 37), the safetysystem 110 can display a subset of interactive account screensassociated with Billy and settings for monitoring and protection ofBilly's device, as shown in FIG. 52. In contrast with the example shownin FIG. 51 (which shows settings for an example parent), the tabsavailable for an example child, Billy, are “profile,” “notifications,”and “devices”—but not “account info.” Similar to the example shown inFIG. 51, a “devices” tab can be available for initiating a link orviewing an existing link with Billy's device(s). As illustrated, settingup a child device can include a snapshot showing devices that have beeninstalled (e.g., by installing on safety system plugin 132 on thedevices 130). Such a snapshot can indicate the name of the child, thename of their device, whether or not a plugin or app has been installedon the device, whether the device is powered on, whether it has a dataconnection, and whether a GPS function is on. This same snapshot caninclude a control that allows a parent to remove the device from theparent's account.

FIG. 52 illustrates an example interactive “profile” screen 5200 forBilly. This view can be generated by or associated with the accountmanagement module 120 of FIG. 1. The “profile” screen 5200 can enableparents to customize monitoring settings for their children's usersystems 130. The settings may include update frequency which can bebalanced with battery life of the user system 130. In some instances,the safety system 110 can send an alert of low battery of one of thechild's user system 130 to a parent's user system. Based on the lowbattery alert, the parents may use safety system 110 to disable some ofthe modules of child's user system 130. In some embodiments, the safetysystem 110 can activate curfew mode on child's user system 130 with alow battery status. The account user interface 5200 may also enableparents to input a child's credentials so that the safety system 110 canuse the credentials to monitor social networking portals. As discussedabove, the safety system 110 can also monitor social networking portalswithout requiring credentials by intercepting via the operating systemof the user system 130.

Setting up a child device can be initiated on that child's mobile deviceas illustrated in FIG. 32. As illustrated in FIG. 52, the process canalso include initiating settings for that child (e.g., using a colorcontrol 5224 to select a color for items viewed relating to that childin a parent interface, using an update control 5228 to select an “updatefrequency” for that child, etc.) Selecting or designating an updatefrequency can include interacting with a control 5228 that comprisesselecting from a drop-down list comprising various intervals—e.g., 5,10, 15, or 30 minutes, 1 hour, 2 hours, etc. The more frequent theupdates, the more rapid battery resources are used, which can affectbattery life of a mobile device. Setting up a child device can furtherinclude social network settings 5212 associating a child's socialnetworks with a safety system 110, which can include gathering log ininformation as a child logs in to a social network site. As indicated at5212, settings can be used to selecting which notifications to receiveregarding that child from a social network (in this case, Facebook).FIG. 53 illustrates an interactive “notifications” screen 5300. Thisinteractive screen is also associated with Billy, as shown. The accountuser interface 5300 further enables parents to customize what type ofalerts they want to receive from safety system 110 related to theirchild's user systems. As shown in the example of FIG. 53, a userinterface can include user controls by which a parent can select one ormore of the following options for which notifications to receive: SMS(if a filtered word is sent or received via SMS or MM, or if the usercontacts a filtered number; WWW (if user tries to access a flagged URL);Curfew (if a user closes the curfew screen); GPS (if GPS is disabled orre-enabled on the device); Device Data (if a data connection to thedevice is lost or reconnected); Apps (if an app is installed oruninstalled); Account (if any account changes are made via the web admininterface). FIGS. 21 and 34 show example interfaces that can be used forthese or similar purposes, in particular when a user desires to updateor change the settings provided when initially setting up a child deviceas described here with respect to FIG. 53.

XXII. COMPUTING SYSTEMS

A number of computing systems have been described throughout thisdisclosure. The descriptions of these systems are not intended to limitthe teachings or applicability of this disclosure. For example, the usersystems and described herein can generally include any computingdevice(s), such as desktops, laptops, video game platforms, televisionset-top boxes, televisions (for example, internet TVs), computerizedappliances, and wireless mobile devices (for example smart phones, PDAs,tablets, or the like), to name a few. Further, it is possible for theuser systems described herein to be different types of devices, toinclude different applications, or to otherwise be configureddifferently. In addition, the user systems described herein can includeany type of operating system (“OS”). For example, the mobile computingsystems described herein can implement an Android™ OS, a Windows® OS, aMac® OS, a Linux or Unix-based OS, or the like.

In some embodiments, the safety system 110 described above may operatewith mobile computing systems using Android OS. As discussed above, theAndroid OS may provide software libraries to access and/or control themobile systems. For example, the safety system 110 can include an AppsAgent, which may use one or more of Android's classes for at least oneof the following operations: retrieve a list of installed apps, retrievea list of uninstalled apps, and track usage of currently installed apps.The Apps Agent may use one or more of the following classes:AppsAgentService, AppsIconService, AppsInstallService,AppsUninstallService, AppsUsageService, AppsUsageSyncService,ProtectedActivity, AppModel, PackageIntentReceiver, or AppsLoader. TheApps Agent can run at specific intervals based on a Frequency AgentService. The App Agent can check for the history of apps installationfrom Android's Package Manager and then check it against the currentlysynced apps from the server. If it is not synced, (for example) then theApp Agent may then check if the app is currently installed to classifyit as installed or uninstalled. If an app is already synced to theserver, the Apps agent may check for the difference (in time) of theapp's launch until it closed.

The safety system 110 can also include a Curfew Agent, which may use oneor more of Android's classes for at least one of the followingoperations: retrieve current date/time, and lock phone. The Curfew Agentmay use one or more of the following classes: CurfewAgentService,ProtectedActivity, Curfew, CurfewManager, or StaticCurfewManager. TheCurfew Agent can retrieve current date and time. The Curfew Agent canrun at specific intervals based on Frequency Agent Service. The CurfewAgent can retrieve a list of pre-identified curfew times from the serverand then check it against the current date and time of the device. Ifthe current date and time retrieved from the server matches the device'scurrent date and time, the Curfew Agent can lock the device and set thelock's password the current WebSafety account logged into the device.

The safety system 110 can also include a Device Status Agent, which mayuse one or more of Android's classes for at least one of the followingoperations: retrieve device's power state, retrieve device's connectiontype (WiFi or cellular) and status, retrieve device's GPS status, andretrieve installation state of the safety system on the mobile device.The Device Status Agent may use one or more of the following classes:Device StatusAgentService, ProtectedActivity, BootCompleteReceiver,NetworkChangeReceiver, or ShutDownReceiver.

The safety system 110 can also include a Location Agent, which may useone or more of Android's classes for at least retrieving the device'sgeographical location. The Location Agent can runs at specific intervalsbased on Frequency Agent Service. The Location Agent can check for thecurrent device's location if a location provider is available (GPS orMobile). If a location provider is available, it can then send thedevice's current location to the server. The Location Agent may use oneor more of the following classes: FuseLocationAgentService,LocationAgentService, ProtectedActivity, and GPSLocationChangeReciever.

The safety system 110 can also include an SMS agent, which may use oneor more of Android's classes for at least retrieving the device's SMSthreads and messages. The SMS agent can run at specific intervals basedon Frequency Agent Service. In one embodiment, the SMS agent can checkfor unsynced message threads from the last 6 hours. If the messagethread is not synced yet, it may flag it as unsynced and send the threaddetails (message thread id, messages, thread sender, and threadreceiver) to the server. Otherwise, if a thread is already synced, theSMS Agent may then check if there are new messages within the thread andsync it to the server per thread accordingly. The SMS Agent may use anSMSAgentService class.

The safety system 110 can also include a WWW Agent, which may use one ormore of Android's classes for at least retrieving device's browsinghistory. The WWW Agent can run at specific intervals based on FrequencyAgent Service. The WWW Agent can retrieve the device's browsing historysince the last query and send it to the server. The WWW Agent may useone or more of the following classes: WWWAgentService or Bookmark.

The safety system 110 can also include a Frequency Agent Service, whichmay use one or more Android's classes for at least retrieving thefrequency of services server synchronization rate. For instance, theFrequency Agent Service can retrieve parent set update frequency fromthe dashboard. The Frequency Agent Service can useUpdateFrequencyAgentService.

Further, the processing of the various components of the illustratedsystems can be distributed across multiple machines, networks, and othercomputing resources. In addition, two or more components of a system canbe combined into fewer components. For example, the various systemsillustrated can be distributed across multiple computing systems, orcombined into a single computing system. Further, various components ofthe illustrated systems can be implemented in one or more virtualmachines, rather than in dedicated computer hardware systems. Likewise,the data repositories shown can represent physical and/or logical datastorage, including, for example, storage area networks or otherdistributed storage systems. Moreover, in some embodiments theconnections between the components shown represent possible paths ofdata flow, rather than actual connections between hardware. While someexamples of possible connections are shown, any of the subset of thecomponents shown can communicate with any other subset of components invarious implementations.

Depending on the embodiment, certain acts, events, or functions of anyof the algorithms, methods, or processes described herein can beperformed in a different sequence or can be added, merged, or left outaltogether (for example, not all described acts or events are necessaryfor the practice of the algorithms). Moreover, in certain embodiments,acts or events can be performed concurrently, for example, throughmulti-threaded processing, interrupt processing, multiple processors orprocessor cores, or on other parallel architectures, rather thansequentially.

Each of the various illustrated systems may be implemented as acomputing system that is programmed or configured to perform the variousfunctions described herein. The computing system may include multipledistinct computers or computing devices (for example, physical servers,workstations, storage arrays, etc.) that communicate and interoperateover a network to perform the described functions. Each such computingdevice typically includes a processor (or multiple processors) thatexecutes program instructions or modules stored in a memory or anothernon-transitory computer-readable storage medium. The various functionsdisclosed herein may be embodied in such program instructions, althoughsome or all of the disclosed functions may alternatively be implementedin application-specific circuitry (for example, ASICs or FPGAs) of thecomputer system. Where the computing system includes multiple computingdevices, these devices may be, but are not required to be, co-located.The results of the disclosed methods and tasks may be persistentlystored by transforming physical storage devices, such as solid statememory chips and/or magnetic disks, into a different state. Each processdescribed may be implemented by one or more computing devices, such asone or more physical servers programmed with associated server code.

Embodiments of the disclosed systems and methods may be used and/orimplemented with local and/or remote devices, components, and/ormodules. The term “remote” may include devices, components, and/ormodules not stored locally, for example, not accessible via a local bus.Thus, a remote device may include a device which is physically locatedin the same room and connected via a device such as a switch or a localarea network. In other situations, a remote device may also be locatedin a separate geographic area, such as, for example, in a differentlocation, building, city, country, and so forth.

Methods and processes described herein may be embodied in, and partiallyor fully automated via, software code modules executed by one or moregeneral and/or special purpose physical computing systems. The word“module” refers to logic embodied in hardware and/or firmware, or to acollection of software instructions, possibly having entry and exitpoints, written in a programming language, such as, for example, C orC++. A software module may be compiled and linked into an executableprogram, installed in a dynamically linked library, or may be written inan interpreted programming language such as, for example, BASIC, Perl,or Python. It will be appreciated that software modules may be callablefrom other modules or from themselves, and/or may be invoked in responseto detected events or interrupts. Software instructions may be embeddedin firmware, such as an erasable programmable read-only memory (EPROM).It will be further appreciated that hardware modules may be comprised ofconnected logic units, such as gates and flip-flops, and/or may becomprised of programmable units, such as programmable gate arrays,application specific integrated circuits, and/or processors. The modulesdescribed herein are preferably implemented as software modules, but maybe represented in hardware and/or firmware. Moreover, although in someembodiments a module may be separately compiled, in other embodiments amodule may represent a subset of instructions of a separately compiledprogram, and may not have an interface available to other logicalprogram units.

In certain embodiments, code modules may be implemented and/or stored inany type of computer-readable medium or other computer storage device(for example, hard disks, RAM, ROM, flash memory, etc.).Computer-readable media include non-transitory computer-readable mediasuch as magnetic storage, optical storage (for example, CD-ROMs orDVDs), semiconductor storage, etc. In some systems, data (and/ormetadata) input to the system, data generated by the system, and/or dataused by the system can be stored in any type of computer datarepository, such as a relational database and/or flat file system. Anyof the systems, methods, and processes described herein may include aninterface configured to permit interaction with other systems,components, programs, and so forth.

Although sometimes described by partitioning functionality of theoverall system into modules for ease of explanation, it is to beunderstood that one or more modules may operate as a single unit.Conversely, a single module may comprise one or more subcomponents thatare distributed throughout one or more locations. Further, thecommunication between the modules may occur in a variety of ways, suchas hardware implementations (for example, over a network, serialinterface, parallel interface, or internal bus), softwareimplementations (for example, database, DDE, passing variables),firmware implementations, a combination of hardware and software, etc.

XXIII DISTRIBUTED MANAGEMENT—O/S CONTROL

In some embodiments, the modules of the safety system 110 aredistributed such that some of the functionality runs locally on themobile device or the user system 130 and other (e.g., the remaining)functionalities run on remote computer systems (see e.g. the remotecomputing system 5540 shown in FIG. 55). For example, the remotecomputing system can be servers operating the portions of the safetysystem 110. The remote computing system can also be the user systems130. The remote computing system can include third party systems 104 orsystem administrator 108. The remote computing system can be accessedover a network 102.

FIG. 54 illustrates an embodiment of a user system which implements somefunctions of a safety system. The user system 130 in FIG. 54 can includehardware such as user system hardware 5440 (e.g., GPS, camera, antenna,and so on), a hardware processor 5450 programmed to execute the varioussoftware modules in the logical blocks, and a memory 5460 configured tostore activity data of the user system 130 as well as various softwareinstructions in the logical blocks. The user system 130 can also includelogical blocks such as a safety system application/plug-in 132, anoperating system 5420, and a local data store 5430.

The local data store 5430 can include instructions for storing activitydata of the user system 130. The safety system application/plug-in 132can include instructions which includes instructions to capture andcommunicate (to a remote computing system) data generated by hardwareblocks such as the user system hardware 5440

As an example, when application software (“app”) or a plugin 132corresponding to the mobile safety system 110 is installed on a usersystem 130, the installation process can create one or more agents orservices 5410 to run in the background along with the operating system5420 (such as Android, iOS, Windows, Linux, etc.) of the user system130. The agents 5410 can collect data, communicate data with remotecomputing system, and control operations of the user system 130. Asafety system plugin 132 can include six agents to implement thefunctionality of the safety system 110 the monitored user system 130: anapps agent, a curfew agent, a device status agent, a location agent, aSMS agent, and a WWW agent. In some embodiments, the mobile safetysystem 110 can also include a general update frequency agent.

A. Apps Agents

In some implementations, the App Agents can perform the followingfunctionalities: adding installed apps to the server, removinguninstalled apps from the server, uploading icons for installed apps,and tracking the amount of time a user uses a particular application onthe user system 130.

Notifying a remote computing system of which apps are installed can behandled by the AppsInstallService class. This service can execute onceevery update cycle, for example. In some embodiments, the update cyclecan be specified by the user. The update cycle can also be determinedbased on the battery life or power management of the user system 130.The AppsInstallService can execute the following steps of a process. TheAppsInstallService can retrieve a list of all apps currently installedon the device by querying Android's PackageManager service. Next, it cancompare this list to the list of apps currently stored in a local sqlitedatabase (db), if any. Any new apps that are not present in the sqlitedb are put into a separate list which is then passed into a newlycreated WSAppsTask object. This task object posts the list of new appsto the server. When this REST request is finished, the task checks ifthe new apps have an icon image associated with them, and if not, sets aflag indicating the icon might have to be uploaded (see below). The taskcan then store the newly reported apps in the sqlite db to be used inthe list comparison during the next update cycle.

See FIG. 74 in this context.

Notifying the server of which apps have been uninstalled can be handledby the AppsUninstallServices class. This service can perform the inverseoperation of the AppsInstallService. Every update cycle, it can querythe list of currently installed apps from the PackageManager and comparethis to the list of apps stored in the sqlite database. If there are anyapps in the database that are not reported as being installed by thePackageManager, they can be stored in a list and passed to a newWSAppsTask object. The task posts the uninstalled apps list to theserver. The uninstall service is notified of the result of the request,and updates the sqlite database to remove the apps that wereuninstalled.

See FIG. 75 in this context.

Uploading the app icons for installed apps can be handled by theAppsIconService class. This service contains logic to initialize aWSUploadAppsIconTask object every update cycle. This task retrieves alist of apps that were previously flagged to upload an icon from thesqlite database. It can then iterate through each app, retrieve the iconimage for the app from the PackageManager service, and upload it to adedicated bucket on the remote computing system. After the upload iscomplete, the task can send an update request to the remote computingsystem to store the URL of the newly created icon image.

The tracking of app usage can be handled by the AppsUsageService andAppsUsageServiceV21 classes. These classes can query app usage data fromthe system and store that data in the local sqlite database by eitherupdating existing records or inserting new records. The differencebetween the two classes is in their implementations, as AppsUsageServiceretrieves the usage data from a service that is deprecated in Androidversion 21, so AppsUsageServiceV21 fills in that gap by using analternate method that requires the user to explicitly grant the mobilesafety system 130 access to usage data. In other operating systems,similar permission access requests may be required. After the data hasbeen stored in the sqlite db, the AppsUsageSyncService class can uploadthe data. It queries the db for all new usage data then passes that listto a WSAppUsagesTask which posts the data to the remote computingsystem. The data may be deleted after transmission to the remotecomputing system.

B. Curfew Agent

In some embodiments, the Curfew Agent comprises the followingfunctionality: retrieving curfew settings from the remote computingsystem, scheduling the locking of the device or user system 130 duringcurfew, scheduling the unlocking of the device after curfew, andnotifying the remote computing system of breaks in curfew. All of thesefunctions can be handled by the CurfewAgentService class.

See FIG. 76 in this context.

Every update cycle (or at another periodic or selectable interval), theservice runs and retrieves an updated list of curfew times from theserver by executing a WSUserCurfewTask instance. This task can performthe logic for both inserting newly created curfews into the local sqlitedb, as well as removing curfews that are no longer present on the server(e.g. the user has deleted or disabled a curfew). The curfew service canlook up the newly stored curfews from the sqlite db and execute thescheduling logic via a WSScheduleCurfewsTask instance.

The WSScheduleCurfewsTask instance can iterate through all curfew datait has been given to decide what events to schedule. If there are noactive curfews, it can cancel all previously scheduled events and starta new instance of the CurfewAgentService class to unlock the device. Theservice can then remove or reset the device password using aWSDevicePolicyManager instance to unlock the device. If theWSScheduleCurfewsTask does have curfews, it can schedule an event tohappen at the beginning of each curfew. Each of these events can triggera new instance of the CurfewAgentService. The service can use theWSDevicePolicyManager to set the password of the device and lock theuser out based on the curfew time.

See FIG. 77 in this context.

The WSScheduleCurfewTask class can also be initialized via theCurfewBroadcastReceiver. This receiver is notified directly by messagessent by the remote computing system when a new curfew is activated or anold curfew is disabled/deleted. This can prompt the schedule task to runand update the state of the phone appropriately in real time. Forexample, this service can be advantageous in some embodiments forparents to remotely disable or activate the mobile devices of theirchildren. In some embodiments, the Curfew Agent can also reportnon-permitted usage of the device during curfew hours. The Agent cancall on the services to check for usage of SMS messages. If the user hassent a text during the curfew hour, the time and violation can bereported to the remote computing system. All time-based orcurfew-related descriptions herein can also apply to other geographic orbehavior-based restrictions.

See FIG. 78 in this context.

C. Device Status Agent

The Device Status agent can update the remote computing system withinformation about the GPS and internet connectivity of the device aswell as the device power and installation status of mobile safety systemplugin or application on the device. In some embodiments, the only datathat is collected on the device is the GPS state. Internet connectivity,power, and the safety system installation can be evaluated from theremote computing system side based on the time since the lastcommunication with the device because it may not be possible for deviceitself to send an update if any of those values are false.

The GPS state can be updated on the device by using the classGPSLocationChangeReceiver. This class can receive notification ofchanges in the location provider configuration sent by the Androidsystem. It then sets a persistent flag depending on whether or not GPSis present in the update location configuration. This flag is then readby the DeviceStatusAgentService class. This service can be executed onceevery update cycle. The service retrieves the latest device state flagsand passes them to a WSSaveDeviceStatusTask instance. This instance thenposts the data to the server.

D. Location Agent

The Location agent can listen for location device updates from thenative (device) location system and can post the updates to the remotecomputing system periodically.

In some embodiments, the location agent is implemented in theWSLocationServiceV2 class. This service registers itself for locationupdates from the operating system's location service. Whenever itreceives an updated location, it checks its accuracy against thepreviously saved location, if any, and also makes sure it is newer thanthe previous location and at least two minutes have passed since thelast update. The elapsed time can be more than two minutes or less thantwo minutes since the last location. If all these conditions are met, itcan store the new location for future comparisons and start aLocationAgentService instance to update the remote computing system.This LocationAgentService instance then posts the new location to theremote computing system using a WSLocationTask instance. It can alsocheck for any unsynced locations in the sqlite database and post them tothe server as well via a WSLocationsTask. Upon completion of theserequests, it can update the local sqlite database with the newly savedlocations.

E. SMS Agent

The SMS agent can obtain the SMS messages that the user has received andsent on the device and sends them to the remote computing system withupdate cycles, for example. The SMS content can be separated intomessages, threads (collections of messages), and users (senders andrecipients of messages).

The SMS agent can be implemented using the SmsAgentService class. Thisservice can be executed every update cycle, and its function is toinitialize a WSSyncSmsTask instance, which can take care of the logicfor retrieving messages. This task operates by checking the time sincethe last update and retrieving any new messages since then, or messagesfrom the past week in the case of the very first update. It retrievesthe messages by performing a query against the operating system'scontent service specifically for the SMS content. It then compares theresults of this query against the current data stored in the localsqlite database to find any messages, users, or threads that are newsince the last update. It then passes these data types to WSMessageTask,WSMessageUserTask, and WSMessageThreadTask instances, respectively.These tasks then post their respective data to the remote computingsystem. On completion, the tasks update the newly retrieved data in thesqlite db for use in the next update cycle.

F. WWW Agent

In some embodiments, the WWW agent can run continuously in thebackground, collecting data from the device's browser and posting it tothe server. The agent can be implemented by the WWWAgentService class.This service can spawn an internal runnable task with the operatingsystem that runs every second or every minute or hour. When this taskexecutes, it triggers the service to evaluate any new browsing activityon the device. Separate implementations may be required depending on thetype of browser that is operating on the device such as the nativeAndroid browser, the Chrome app, and the custom browser installed onSamsung phones. The class can handle different browsers by retrievingdata directly from the operating system. The agent can retrieve a listof recent websites from the operating system's content service using aspecific URI for each browser. In some embodiments, it will only requestbrowsing data since the last update time. Once it has retrieved thisdata, it saves it to the local sqlite db and passes it to a newWSUserUrlTask instance. This task can then post the data to the remotecomputing system.

G. Update Frequency Agent

The Update Frequency Agent can coordinate the frequency of updates amongthe agents of the mobile safety system 110. The agent can include aservice class for checking new update frequency against the cached valueand restart agent services if necessary. If the update frequency haschanged, the preferences are updated and all agent services may berestarted to use the new update interval.

See FIG. 79 in this context.

H. Additional Implementation Details

Agents can be implemented, for example, using programming languages suchas C, C++, Java, Javascript, etc. Following is an example structure of apackage developed using JAVA to implement the agents of the mobilesafety system 110 on a user system 130. The machine code generated basedon compiling the programmed instructions can be executed by the hardwareprocessor of the user system 130.

Service Classes: The ‘service’ classes can run in the background andoperate at timed intervals. The timing may be a function of batterymanagement as discussed above. In some embodiments, the interval can beone minute or less, for example. The service classes can enableoperational functionality for each agent. Their general executionpattern is to retrieve information from a database relevant to theiragent (e.g. list of apps, sms agents, etc.) and then spin off a relevant‘task’ which will then upload this data to one or more remote servercomputers or data repositories. Each task may correspond to aninstantiation of an object of a “task” class described below. The tasksmay be added to a queue for execution at a later time. The retrieveddata may come from the local sqlite database that is managed by themobile safety system 110. The retrieved data may also come from otherresources such as the operating system by the task that is started. Forexample, the SMS data may be retrieved from the operating system.

Tasks Classes: The ‘task’ classes can be started by the service class ofthe corresponding agent. Some of the instantiations of the task objectcan execute immediately upon being created. The task class may beinstantiated with a list of data that needs to be sent to the server, atwhich point they will execute a REST call to post that data to theappropriate endpoint. REST call relates to Representational StateTransfer service to manage states of Web Services. Some of these (suchas sms) may not be given data directly by the service and will insteadquery the operating system directly for the relevant information.

AppsLoader Task Class: The AppsLoader class can retrieve a list ofinstalled applications. For instance, the class can import packages fromthe operating system to retrieve information about the installedapplications. For an Android OS, the imported packages can includeandroid.content.Context, android.content.pm.ApplicationInfo,android.content.pm.PackageManager, andandroid.support.v4.content.AsyncTaskLoader. The “Context” class enableinterface to global information about an application environment. It canallow access to application-specific resources and classes, as well asup-calls for application-level operations such as launching activities,broadcasting and receiving intents, etc. The PackageManager class can beused to retrieve various kinds of information related to the applicationpackages that are currently installed on the user system 130.

The AppsLoader class can deliver the result if it already has a list ofcurrently installed Apps. The AppsLoader can also attach to a process ofthe operating system to listen for changes such as when an applicationis installed or uninstalled. For example, when a user clicks on theuninstall button under the Manage Apps settings of an Android operateduser system, the system 130 can listen by calling“com.android.packinstaller.UninstallerActivity”. After the informationis transferred to the server, the AppsLoader class can release theresources.

Request Classes: The ‘request’ classes can be used to send specifictypes of data to one or more remote computers. In some embodiments,there is a dedicated request class for each type of data that is handled(e.g. one for sms messages, one for websites visited, and location).They are generally instantiated in a task or sometimes a service with aset of data and can then execute a REST call with that data to theserver.

Models Classes: These ‘model’ classes can be used to represent differentdata types or data structures (e.g. an sms message, a location point,and curfew) as JAVA objects. Instances of these models can beconstructed from database information when a query is executed by aservice or task, and are then sent to the remote computer via requestobjects.

Receiver Classes: In some embodiments, most of the agents are executedat timed intervals and collect information at these intervals. However,certain types of data may be collected reactively in response tosystem-level events. For instance, the location agent may collect datawith each significant location change, the timing of which cannot bepredicted. These receivers accomplish this by registering with theoperating system to be notified by some specific system event. Then,whenever this event happens, they will retrieve the new data andgenerally store it in the local sqlite database to be retrieved by therelevant service at the next update interval. In some embodiments, thereceivers can trigger an update immediately by directly executing theagent's relevant service (such as sms). For example, aSMSBroadcastReceiver class can implement the SMS monitoring service. Foran Android OS, the SMSBroadcastReceiver class can import“android.content.BroadcastReceiver”, “android.content.Context”,“android.content.Intent”, “android.telephony.SmsMessage”, and“android.util.Log”. The SMSBroadcastReceiver class can register withAndroid to receive an event in response to the user system sending orreceiving SMS messages. The sent or received SMS message is stored inthe SMSMessage class for to be transferred to the remote computer.

Some agents may operate differently than other agents. Instead of justcollecting information on the device and sending it to the server, thecurfew agent also responds to updates sent from the server concerningupdated curfew times. The receiver class for the curfew agent listensfor curfew update events that are broadcasted by the server to thedevice, and when it is notified of a change, it initiates the curfewagent's service class to appropriately respond to the update. Thisresponse can be locking down the phone if an new active curfew has beenadded, unlocking the phone if an existing active curfew has beendisabled, or simply storing the new curfew information for later use.For example, the CurfewBroadcastReceiver class can import“android.os.PowerManager” to control the power state of the user system130.

XXIV. DISTRIBUTED MANAGEMENT: SERVER CONTROL

This disclosure hereby incorporates by reference paragraphs 302-332,under the heading of “Distributed Management: Server Control,”(discussing FIGS. 55-60) of U.S. patent application Ser. No. 16/355,367.

XXV. ADDITIONAL EXAMPLE USER INTERFACES OF THE SAFETY SYSTEM

This disclosure hereby incorporates by reference paragraphs 333-334,under the heading of “Additional Example User Interfaces of the SafetySystem,” (discussing FIGS. 61A, 61B, 62A, 62B, 63-65, 66A, 66B, and67-72) of U.S. patent application Ser. No. 16/355,367.

A. Example User Interfaces for Signing-Up with and Signing-in to theSafety System

This disclosure hereby incorporates by reference paragraphs 335-345,under the heading of “Example User Interfaces for Signing-up with andSigning-in to the Safety System,” (discussing FIGS. 61A-62B) of U.S.patent application Ser. No. 16/355,367.

B. Example User Interface on a Parent Device for Viewing Activities of aChild Device

This disclosure hereby incorporates by reference paragraphs 346-365,under the heading of “Example User Interface on a Parent Device forViewing Activities of a Child Device,” (discussing FIGS. 63-71) of U.S.patent application Ser. No. 16/355,367.

C. Example User Interface for Configuring Notification Settings

This disclosure hereby incorporates by reference paragraphs 366-372,under the heading of “Example User Interface for ConfiguringNotification Settings,” (discussing FIGS. 72-73) of U.S. patentapplication Ser. No. 16/355,367.

XXVI. INCENTIVES AND ADMINISTRATIVE CONTROLS

This disclosure hereby incorporates by reference paragraphs 373-380,under the heading of “Incentives and Administrative Controls,” of U.S.patent application Ser. No. 16/355,367.

XXVII. ADDITIONAL EMBODIMENTS AND EXAMPLES

This disclosure hereby incorporates by reference paragraphs 381-425,discussing 45 aspects under the heading of “Additional Embodiments andExamples,” of U.S. patent application Ser. No. 16/355,367.

Terminology and Conclusion

Conditional language used herein, such as, among others, “can,” “might,”“may,” “for example,” and the like, unless specifically statedotherwise, or otherwise understood within the context as used, isgenerally intended to convey that certain embodiments include, whileother embodiments do not include, certain features, elements and/orstates. Thus, such conditional language is not generally intended toimply that features, elements and/or states are in any way required forone or more embodiments or that one or more embodiments necessarilyinclude logic for deciding, with or without author input or prompting,whether these features, elements and/or states are included or are to beperformed in any particular embodiment. The terms “comprising,”“including,” “having,” and the like are synonymous and are usedinclusively, in an open-ended fashion, and do not exclude additionalelements, features, acts, operations, and so forth. Also, the term “or”is used in its inclusive sense (and not in its exclusive sense) so thatwhen used, for example, to connect a list of elements, the term “or”means one, some, or all of the elements in the list. In addition, thearticles “a” and “an” are to be construed to mean “one or more” or “atleast one” unless specified otherwise.

Conjunctive language such as the phrase “at least one of X, Y and Z,”unless specifically stated otherwise, is otherwise understood with thecontext as used in general to convey that an item, term, etc. may beeither X, Y or Z. Thus, such conjunctive language is not generallyintended to imply that certain embodiments require at least one of X, atleast one of Y and at least one of Z to each be present.

While the above detailed description has shown, described, and pointedout novel features as applied to various embodiments, it will beunderstood that various omissions, substitutions, and changes in theform and details of the devices or algorithms illustrated can be madewithout departing from the spirit of the disclosure. Thus, nothing inthe foregoing description is intended to imply that any particularfeature, characteristic, step, module, or block is necessary orindispensable. As will be recognized, the processes described herein canbe embodied within a form that does not provide all of the features andbenefits set forth herein, as some features can be used or practicedseparately from others. The scope of protection is defined by theappended claims rather than by the foregoing description.

Reference throughout this specification to “some embodiments” or “anembodiment” means that a particular feature, structure or characteristicdescribed in connection with the embodiment is included in at least someembodiments. Thus, appearances of the phrases “in some embodiments” or“in an embodiment” in various places throughout this specification arenot necessarily all referring to the same embodiment and may refer toone or more of the same or different embodiments. Furthermore, theparticular features, structures or characteristics may be combined inany suitable manner, as would be apparent to one of ordinary skill inthe art from this disclosure, in one or more embodiments.

As used in this application, the terms “comprising,” “including,”“having,” and the like are synonymous and are used inclusively, in anopen-ended fashion, and do not exclude additional elements, features,acts, operations, and so forth. Also, the term “or” is used in itsinclusive sense (and not in its exclusive sense) so that when used, forexample, to connect a list of elements, the term “or” means one, some,or all of the elements in the list.

Similarly, it should be appreciated that in the above description ofembodiments, various features are sometimes grouped together in a singleembodiment, figure, or description thereof for the purpose ofstreamlining the disclosure and aiding in the understanding of one ormore of the various inventive aspects. This method of disclosure,however, is not to be interpreted as reflecting an intention that anyclaim require more features than are expressly recited in that claim.Rather, inventive aspects lie in a combination of fewer than allfeatures of any single foregoing disclosed embodiment. Accordingly, nofeature or group of features is necessary or indispensable to eachembodiment.

A number of applications, publications, and external documents may beincorporated by reference herein. Any conflict or contradiction betweena statement in the body text of this specification and a statement inany of the incorporated documents is to be resolved in favor of thestatement in the body text.

Although described in the illustrative context of certain preferredembodiments and examples, it will be understood by those skilled in theart that the disclosure extends beyond the specifically describedembodiments to other alternative embodiments and/or uses and obviousmodifications and equivalents. Thus, it is intended that the scope ofthe claims which follow should not be limited by the particularembodiments described above.

What is claimed is:
 1. A computer system for distributing management ofa parent-controllable safety monitoring system, the computer systemcomprising: one or more child mobile devices, each having an operatingsystem and a plurality of applications installed thereon; at least onemobile safety application installed on each of the one or more childmobile devices, the mobile safety application configured to: run in thebackground along with the operating system of the child mobile device;collect child data from other applications of the plurality ofapplications installed on the same child mobile device; communicate thechild data to a remote computing system; and control operations of thechild mobile device; the at least one mobile safety application furthercomprising the following local agents: an apps agent configured toperiodically review a memory of the child mobile device to identify oneor more installed applications and usage times for those installedapplications; a curfew agent configured to retrieve curfew settings fromthe remote computing system, schedule and implement curfew actions onthe child mobile device based on the curfew settings, and notify theremote computing system of attempted curfew violations; an SMS agentconfigured to periodically review the memory of the child mobile deviceto identify content of sent and received texts; and a WWW agentconfigured to collect browser data; at least one local agent in themobile safety application configured to transmit collected informationfrom the child mobile device to the remote computing system; a parentinterface for display on a parent mobile device configured to acceptparent input to establish parent parameters regarding content andfrequency of child device updates and warnings; a remote databaseconfigured to receive periodic updates from the child mobile device; andthe remote computing system configured to receive the collectedinformation associated with the one or more child mobile devices, parsethe collected information to determine a data type and select anappropriate flagging algorithm and database based on the determined datatype; perform at least one analysis algorithm on the parsed, collectedinformation by comparison to the selected database, analyze thatinformation as indicated under the parent parameters, and flaginappropriate child activity based at least partly on the analysis ofthe collected information, thereby offloading processing loads frommobile devices to the remote computing system, reducing system lag, andimproving accuracy of any warnings, curfew actions, and controloperations recommended or automatically implemented on the child mobiledevice.
 2. The computer system of claim 1, wherein the remote databasecomprises a backup storage system associated with an iOS operatingsystem.
 3. The computer system of claim 1, wherein the remote computingsystem is further configured to: receive parent parameters from theparent mobile device; and transmit data packets to the one or more childdevice causing the at least one mobile safety application associatedwith respective child devices to collect the child data and control theoperation of the respective child devices in accordance with the parentparameters.
 4. The computer system of claim 1, wherein the remotecomputing system is further configured to send a notification of theflagged inappropriate activity to the parent mobile device.
 5. Thecomputer system of claim 1, wherein the remote computing system isfurther configured to: identify the child mobile device associated withthe flagged inappropriate activity and cause the mobile safetyapplication to inhibit a function of the child mobile device.
 6. Thecomputer system of claim 1, wherein control operations of the childdevice comprises: accessing a list of restricted applications;identifying whether the plurality of applications includes one or moreapplications on the list of restricted applications; in response to adetermination that the plurality of applications includes the one ormore applications on the list of restricted applications, inhibiting oneor more interactions with identified applications on the child mobiledevice.
 7. The computer system of claim 1, wherein the apps agent isfurther configured to perform one or more of the following: restrictingpurchase or preventing download of a predetermined application.
 8. Thecomputer system of claim 1, wherein the curfew actions comprise one ormore of the following: blocking access to one or more applications onthe child mobile device; inhibiting interactions with one or moreapplications on the child mobile device; or locking the child mobiledevice periodically thereby requiring repeated logins on the childmobile device.
 9. The computer system of claim 1, wherein the localagents further comprises one or more of the following: a device statusagent configured to update the remote computing system with at least oneof the following information of the child device: GPS data, internetconnectivity, device power and installation status of one or moreapplications on the child device; a location agent configured to acquirelocation data from the child mobile device and transmit the locationdata to the remote computing system periodically; or an update frequencyagent configured to coordinate frequency of updates for agents of thelocal agents.
 10. The computer system of claim 1, wherein the collectedinformation comprises encoded information, and wherein the remotecomputing system is further configured to decode the collectedinformation and parse the collected information.
 11. A method for usinga remote computing system to monitor one or more child computingdevices, said method comprising: identifying a child computing device,the child computing device comprising a plurality of applicationsincluding a mobile safety application programmed to monitor and controlthe child computing device; generating a default configuration file formonitoring and controlling the child computing device; transmitting thedefault configuration file to the child computing device; receivingdevice activity data associated with the child computing device, whereinthe device activity data is encoded; decrypting and parsing the deviceactivity data to obtain information on usage of one or more applicationsof the plurality of applications on the mobile device; determining adata type of the parsed device activity data and selecting anappropriate flagging algorithm and database based on the determined datatype; performing at least one analysis algorithm on the parsed,decrypted device activity data by comparison to the selected database;analyzing the information to identify one or more inappropriateactivities; flagging the inappropriate activities; and transmitting atleast the flagged inappropriate activities to a parent computing device.12. The method of claim 11, wherein the mobile safety applicationcomprises at least one of the following agents: an apps agent configuredto periodically review a memory of the child mobile device to identifyone or more installed applications among the plurality of applicationsand usage times for those installed applications; a curfew agentconfigured to access curfew settings, schedule and implement curfewactions on the child mobile device based on the curfew settings, andnotify the parent computing device attempted curfew violations; an SMSagent configured to periodically review the memory of the child mobiledevice to identify content of sent and received texts; a WWW agentconfigured to collect browser data; a device status agent configured tomonitor at least one of the following information of the child device:GPS data, internet connectivity, device power and installation status ofone or more applications of the plurality of applications on the childdevice; a location agent configured to acquire location data from thechild mobile device and transmit the acquired location data; or anupdate frequency agent configured to coordinate frequency of updatesamong the agents.
 13. The method of claim 11, further comprising:receiving an update to the default configuration file; and transmittinga notification with the update to the child mobile device, thenotification causes the child mobile device to update settings of thechild mobile device based at least partly on the update to the defaultconfiguration file.
 14. The method of claim 11, wherein device activitydata comprise at least one of the following: device location, browsinghistory, content of social network posts, or application installationstatus.
 15. The method of claim 11, further comprising: accessingcriteria associated with inappropriate activities and flagging theinappropriate activities based on the accessed criteria.
 16. The methodof claim 15, wherein the criteria are directed toward at least one ofthe following: location of the child device, word usage in a message,website browsing, or installation of applications on the child mobiledevice.
 17. The method of claim 11, wherein transmitting at least theflagged inappropriate activities to the parent computing devicecomprises: generating user interface data comprising: visual indicatorsassociated with the flagged inappropriate activities and descriptions ofthe flagged inappropriate activities.
 18. The method of claim 11,wherein receiving device activity data is performed by communicatingwith at least one of the following: one or more applications of theplurality of applications or a backup data storage configured toregularly receive device activity data from the child mobile device. 19.A system for improving processing efficiency to allow parents to reducedelay in tracking smart phone activities of their children, the systemcomprising: one or more child software modules, a module installed oneach child's smart phone, each child software module configured to:obtain device activity data from or about more than one of the smartphone's other software applications; and package the device activitydata to avoid parsing and analysis on a local smart phone processor;send the device activity data to an analysis server; the analysisserver, configured to: decrypt the device activity data; parse thedecrypted device activity data to determine a data type and select anappropriate flagging algorithm and database based on the determined datatype; perform at least one analysis algorithm on the parsed, decrypteddevice activity data by comparison to the selected database; and aparent interface on a mobile device configured to: receive and displayresults of the analysis algorithm; provide visual warnings when harmfulresults have been found by the analysis algorithm, along with access tomore details relating to the specific underlying data that triggered thewarning; provide an interface for receiving input from a parent, theinput comprising: selections of which child's data to view; andselections of which types and how much of the data and analysis resultsto view for each child.
 20. The system of claim 19, wherein the analysisserver is configured to parse the decrypted device activity data toassociate at least one child software modules with the decrypted deviceactivity data.
 21. The system of claim 19, further comprising adistributed management computer system for distributing management of aparent-controllable safety monitoring system, the distributed managementcomputer system comprising: a non-transitory computer memory; and aprocessor programmed to: identify a child computing device, the childcomputing device comprising a plurality of applications including amobile safety application programmed to monitor and control the childcomputing device by at least collecting device activity data from one ormore applications of the plurality of applications on that device foranalysis; generate a default configuration file that comprises settingsfor monitoring and controlling the child computing device; transmit thedefault configuration file to the child computing device, therebyimposing the settings on the child computing device; receive thecollected device activity data associated with the child computingdevice, wherein the device activity data is encoded; decrypt and parsethe device activity data to obtain information on usage of the one ormore applications on the mobile device; determine a data type of theparsed device activity data and select an appropriate flagging algorithmand database based on the determined data type; perform at least oneanalysis algorithm on the parsed, decrypted device activity data bycomparison to the selected database; analyze the information to identifyone or more inappropriate activities based at least partly on thedecrypted and parsed device activity data; flag the inappropriateactivities; generate user interface data comprising informationidentifying the inappropriate activity; and transmit the user interfacedata to a parent computing device, thereby allowing a parent to monitorchild activity.
 22. The system of claim 21, further comprising adistribution system for distributing management of a parent-controllablesafety monitoring system, the distribution system comprising: a firstcontrol system configured to be executed on one or more hardwareprocessors of a child mobile device and further configured to: run inthe background along with an operating system; collect device activitydata associated with a plurality of applications on the child mobiledevice; and communicate the device activity data to a second controlsystem; the second control system configured to be executed on one ormore hardware processors on a network computing system remote from thechild mobile device and a parent computing device and further configuredto: receive the device activity data associated with a plurality ofapplications on the child mobile device; determine a data type of thedevice activity data and select an appropriate flagging algorithm anddatabase based on the determined data type; perform at least oneanalysis algorithm on the parsed, decrypted device activity data bycomparison to the selected database; access parent parameters, theparent parameters comprising settings for monitoring content ofcommunications on the child mobile device, frequency of the child mobiledevice updates, and warnings associated with content of the deviceactivity data; analyze the device activity data based at least partly onthe parent parameters; flag an inappropriate child activity based atleast partly on the analysis of the device activity; generate userinterface data comprising: information identifying the inappropriateactivity; and transmit the user interface data to a third controlsystem; and the third control system configured to be executed on one ormore hardware processors of the parent computing device and furtherconfigured to: receive the user interface data from the second controlsystem; display the user interface data on the parent computing device;receive an update on one or more of the parent parameters; and generatea data packet comprising the update and computer executable instructionsto implement the update on at least one of the first control system orthe second control system.
 23. The distribution system of claim 22,wherein the data packet comprising the update is configured to controlthe child mobile device by decreasing or increasing at least one offunctionality and child access to the child mobile device features.